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. b466b3bc60.
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
In some cases, the footer in a form view dialog could be duplicated.
The reason was that the form view was rerendered completely, footer
included, by the renderer, out of the formcontroller control (it is the
formcontroller's job to move the footer buttons to the footer).
A possible fix is to work on the form renderer to make it aware that the footer
buttons are expected to be only rendered once, but it has the disadvantage to
be a fix specific to this issue, and any other form view behaviour with some
side effects may have the same issue.
This commit tries to prevent the form view from rerendering itself
completely in those cases. This also has the disadvantage of possibly
not being a complete fix, if some edge cases are missed. However, I
have the feeling that we still want to avoid rerendering the full view
if possible.
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.
Before this rev., sorting groups in list views wasn't supported. It
hadn't been implemented in the new views.
This rev. activates the feature, so groups can now be sorted on
their aggregates again. It also implements a basic (first level
only) sorting in mockReadGroup, in the mock server.
opw 781288
In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget. As a result, the environment was not properly
restored at the end.
In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)
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.
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").
With this commit, we prevent view dialogs from changing the 'global'
environment in the view manager. Here is how it could cause a problem:
* open a form view for a bill of material
* click on one of the component, it will open a form view in a dialog
(and will change the environment with a wrong res_id)
* click on the many2one product -> it will open a new action in the
background, and change the environment again
* click on the breadcrumb to come back to the bill of material: the view
manager will try to restore the correct res_id (which is the wrong id
from the component form view), the form view will do a read (when
reloading the data), will get an empty result, will update its
information with no data, then will be in a wrong state which means
that the basicmodel will fetch a x2many with a wrong res_ids list
* boom
Christophe Simonis