| Age | Commit message (Collapse) | Author |
|---|
|
Since fbf347498f1cc7b74ef373179b7bcae201715c24, when opening a view in a
dialog, the favorite filters were not loaded.
For example on the runbot:
1. In CRM, open any lead, edit it, and open the Customer dropdown
2. Create a custom filter, save it as favorite, and close the dialog
3. Open the dialog again: you don't see your new filter
With this commit, you will see your filter at step nr. 3
closes odoo/odoo#59180
X-original-commit: 418013e8dbb2aa2d4ffd4f650f080ca5a94183f9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
|
|
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closes odoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
|
|
Purpose
=======
In Social, we want to be able to change the "Save" button into a "Add"
button when we add a new stream. For that purpose, we need to be able to
customize the text of the `FormViewDialog` buttons.
Task-2234580
See odoo/enterprise/pull/9933
closes odoo/odoo#49622
Related: odoo/enterprise#9933
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Some web actions/controllers/viewsl have been adapted to properly instantiate the
newly refactored control panel and update it accordingly. We needed to adapt the
starting mechanism of actions and controllers to ensure that the control panel
instantiation did not delay the loading of any widget.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
|
|
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
Task 2068280
|
|
This commit adds two methods as hooks to customize the way Dialog deals
with its buttons :
* _setButtonsTo() : to render and set the buttons into a container
element;
* _setRemoveButtonOption() : to define the remove button and
set its destination zone (header, footer)
Task ID: 2038324
closes odoo/odoo#35474
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Dharmang Soni <dpr@odoo.com>
|
|
This function was too long and it's now easier to override it
in enterprise
Task ID : 1924779
|
|
- many2one widget in mobile will open kanban view instead of listview when
records needs to be selected
- Add support of "kanban_view_ref" on many2x fields:
For many2one fields, this specific kanban view will be opened when you click
on this field. Note that in desktop, the behavior stay unchanged:
'Search More' will open the tree view.
For many2many fields, this specific kanban view will be opened when you add
a record in mobile.
- Add support "selection_mode" in kanban views.
This boolean is set to true when you want to use a kaban view to
select a record instead of open a record.
"selection_mode" is now passed in qweb_context to allow developers
to use t-if='selection_mode' in kanban views to show or hide elements;
buttons, dropdowns, anchor tags are not necessary when selection_mode
is enabled. So those elements can be hidden based on this condition.
Useful when kanban view is opened from m2o in mobile environment.
Task ID : 1924779
|
|
|
|
|
|
closes odoo/odoo#35119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
|
|
When opening a dialog using mouse and closing it, form_dialog_discarded is
triggered, which tries to set focus on form while lastActivatedFieldIndex
is -1, as dialog is opened using mouse directly
do not set focus back to form widget if lastActivatedFieldIndex is -1
task-2031706
closes odoo/odoo#34684
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
Before this rev. the searchpanel could only be activated in kanban
views (and it was specified in the kanban arch). From now on, the
searchpanel can be activated in any multi record view. It's arch
is moved to the search view arch (inside the <searchpanel> tag).
Task 1985921
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
|
|
|
|
Let's assume a many2one field with a lot of possible values. The
user clicks on 'Search More...'. In the opened dialog, only 160
records are available (their ids have been obtained with a
name_search, with the optional text the user could have typed in
the many2one input).
Before 4cd379cf, that extra domain on ids was removed automatically
as soon as the user interacted with the search view in the dialog.
This was especially useful when there were more than 160 records.
However, this was rather an happy coincidence than a designed
feature.
From 4cd379cf, the ids selection was added to the initial domain
of the list, so they couldn't be removed from the domain
afterwards. The user was thus stucked with its preselected 160
records.
This rev. doesn't restore the former behavior, but rather improves
the current one, as follows:
- when there is no text in the many2one input (i.e. no value to
filter on), we bypass the name_search, s.t. all records are
available in the dialog
- when there is some text in the input, we perform a name_search (as
before) to get a list of record ids, and we add a special filter
to the search view in the dialog (the filter on those ids), s.t.
the user can remove it if he wants to access the remaining records.
- finally, the limit is now set to 320, to mitigate the problem
Issue reported on the saas-12.1 migration pad.
closes odoo/odoo#31232
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
- Hide the "Remove" button on the create modal's footer.
- Update title when click on "Save & new" button
Task ID: 1924887
closes odoo/odoo#30209
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
|
|
|
|
On a form view (of model A), define a many2one (model B) with a [form|tree]_view_ref context key
In that view, have a x2m field (model C) with a different [form|tree]_view_ref context key
Before this commit, the second load_views (i.e. on the model C) crashed because
the wrong context key was sent to the server, which returned the view to which the _view_ref points
i.e. the view of the model B
After this commit, we clean the context of subviews loading, because those keys are only useful for the python
and one shot. Hence, there is no crash
OPW 1903780
closes odoo/odoo#28260
|
|
|
|
|
|
Start on the modal obtained by a "search more". The offset is never reset.
So suppose you are on page 2, looking at record 81-160.
Do a research that gives less than 80 records.
The result of the search is nothing, since is has been done with a 80 offset.
It should be reset to 0 when we do a new search.
opw 1920826
closes odoo/odoo#30109
|
|
Fixes #26629
|
|
Currently, to remove link of x2m field from any record, sometimes there's no way.
For example, if we are on mobile and open any Quotation, it's linked quotation lines
are automatically converted in kanban, and there is no way to delete a line from
that quotation. However, in some of the manually designed kanban, there is special 'x'
for removing / unlinking x2m record, for example, Contacts of Partner.
This commit makes the behavior more consistent. During edition (mobile and desktop), if
a view dialog is opened on click of x2m field, it will have one 'Remove' button (based
on user rights) on right side of dialog footer, allowing users to delete / unlink the
record. Moreover, in mobile, the modal is opened fullscreen, with sticky header and
footer.
Related Task# : 31641
Closes PR #15857
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.
|
|
The pyeval name is quite confusing, given that there is already an eval
and an evaluate function in py.js, and that the web.pyeval exports two
evaluate functions.
Since this file is more about odoo specific customization to py.js, it
is renamed in py_utils to better express its intended use.
|
|
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
|
|
|
|
On an editable line with a many2one
Click to create a record
Click on create a record in the many2one
It opens the form view of the object in a modal, which has a many2many list, which choices are domainized
Click 'add an item' on this list
It should open a modal with the filtered choices
Click on any of the existing record
Before this commit:
There was a traceback in JS
That was because the event bubbled up to a parent, when it shouldn't
After this commit:
The whole flow unfolds without errors
OPW 1823205
|
|
This is a manual forwardport of rev. b466b3bc608.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it crashed because it tried to retrieve the
action's context (to add to the saved filter), whereas there is no
action in this case.
Actually, the action's context should never been used in this case.
What must be used is the controller's context (this mainly makes
sense for Pivot and Graph views).
Fixes #23293
|
|
This is a manual forwardport of rev. b466b3bc.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
controller in the closest instance of a ViewManager-like widget
in the SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes #23293
|
|
|
|
*: mail, web_diagram
|
|
This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.
The main changes are:
- there is no ViewManager anymore, its work is now handled by the
ActionManager itself, but isolated in a specific file ; this
eases a lot of things, as the breadcrumbs handling for example.
- the ActionManager code is converted to the new coding principles
and guidelines ; mainly, children widgets communicate with it by
triggering events up, and not by function calls anymore.
- the ActionManager layer is now testable, and a lot of tests have
already been written.
- the code in other addons has been adapted consequently.
What's coming next:
- introduce the 'AbstractAction' Widget, and make client actions
and view controllers inherit from it ; this widget will
implement a common API that could be used uniformly by the
ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
getTitle()...).
- move the ControlPanel handling from the ActionManager to the
AbstractAction.
|
|
*board,sale_timesheet
This rev. changes the API of load_views, as it now assumes that
the given context has no longer to be evaluated. This is more
convenient that way, as we can now call load_views with contexts
that are dict, and not instances of the Context class.
|
|
|
|
Here is a scenario that could cause an issue:
- open a form view with a many2one
- click on edit button
- click on small external button for many2one. this opens a modal form
view
- click on save in the modal (without changing anything)
- click on save in the main record
- exit form view. this opens a discard dialog
There were two issues here:
- saving the modal dialog automatically marks the many2one field as changed.
This was necessary to force reloading the data, because editing a sub value
in the modal form view could have changed the display_name of the manyone
field. However, this is not necessary when no change was done.
- when saving a record, the _isDirty flag was reset to false only if an
actual rpc was done. However, it may happen that the flag is set to
dirty (for example, when modifying a value inside a many2one), but the
main record has no changed fields.
In this commit, we also remove the on_save handler in the
formviewdialog. This is a small refactoring in a stable version, but no code
currently use it, and I believe that it will make the code much easier
to maintain (the previous code was really awkward), so I think that the
tradeoff is acceptable.
|
|
An error occurred if the domain or context applied on a view
opened in a dialog needed to be evaluated (e.g. if they contained
something like [['some_field', '=', uid]]). For instance, create
a custom filter with such a domain for the Contact model, then go
to Contact, create a new one, and on the parent_id many2one, click
on search more. Before this rev, no eval context was given so the
domains and contexts couldn't be evaluated, and it crashed.
|
|
|
|
When selecting a partner in the reconciliation widget, using the SelectCreateDialog
(Search More), the partner wasn't correctly displayed.
This was due to a difference between the change format of the many2one ; when using
the dialog, only the `id` is sent (while the `id` and `display_name` are sent when
using the many2one dropdown).
These two behaviours are now standardized and both now send `id` and `display_name`.
It has the advantage of sparing some `name_get`s called by the model because the
`display_name` was missing.
This change implies some refactoring where the SelectCreateDialog was used.
|
|
|
|
There were some coding mistakes since some changes introduced by
https://github.com/odoo/odoo/commit/d19671f0d0ff7189055cbe0794afed32f8a387e6
|
|
As its name indicates, the SelectCreateDialog is meant to select and create,
not edit.
If the view is editable, clicking on an element will edit it instead of
selecting it. For this reason, the view is set in `readonly` even if the view
arch uses the attribute `editable`.
Before this rev., you couldn't select a "Close Reason" when closing a
subscription (in "Search More").
|
|
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
|
|
before this fix: the domain is used when opening the dialog but it is not
used if the user update the filter or the group_by.
|
|
Ultimately, it seems that sending the value of readonly fields
when saving is not such a good idea. Suppose that there is a
computed field displayed as readonly in a form view. This field is
computed from other records, e.g. from a one2many field which is
editable in the form view. Finally, the inverse function of the
computed field creates the one2many records. If the user adds some
records to the one2many, then saves, the readonly computed field's
value is sent to the server as well, and thus the inverse function
is executed, which isn't what we want.
This commit essentially reverts 0494d61274, except that we now take
into account the readonly modifier to determine whether or not a
value is sent to the server, and not only the readonly attribute of
the field (which can be seen as a default). Before rev. 0494d61274,
we made a difference between write and create RPCs, for an unclear
reason. We don't do that anymore: readonly fields are never sent to
the server (same behavior as before the new views).
|
