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
Aaron Bohy