The CompoundDomain class allows to regroup several domains with an
implicit "AND"; these domains can be either a string, an array or
another CompoundDomain. A CompoundDomain can then be converted to
an array thanks to pyeval.js.
For example, if a CompoundDomain is initialized with `[A, B]` and
`[C]`, the array conversion gave `[A, B, C]` (which is expected).
However, a hackish method was used with CompoundDomain. If one of the
domain of a CompoundDomain is equal to `["|"]` (an array with the
OR operator in it), the two next subdomains were supposed to be joined
by a OR operator. Indeed, for the case of a CompoundDomain initialized
with `["|"]`, `[A]` and `[B]`, the array conversion gave `["|", A, B]`
(which is expected). However, if initialized with `["|"]`, `[A, B]` and
`[C]`, the array conversion gave `["|", A, B, C]` which is very wrong
as what was expected is `["|", "&", A, B, C]`. The problem is that the
given `[A, B]` contains implicit "&" operators.
This commit fixes the problem by normalizing only if the CompoundDomain
starts with a ["|"] or ["!"] array which is the standard odoo case.
This allows to limit breaking custom code (e.g we want a simple "AND"
of `[A]` and `[B]` to stay `[A, B]`, not become `["&", A, B]`).
The commit also modifies a test so that it checks that the problem is
properly solved.
Rev e37ba61 forward-ported 8.0 revision f02b230 from PR #12379.
This patch introduces extra tests and views for o2m onchange behavior,
including new fields in the test models.
In 9.0 a new convert_to_onchange() mechanism had been
introduced at 9f81c6d
The combination of both requires some adaptation to the
expected results of the new tests and adaptation of existing tests.
The test models in `test_new_api` have an implicit depencies between
models which cannot be express on ORM:
messages depends on participants of their discussion.
So, when editing a discussion, the field `participants` should be
processed before field `messages`. This is not always done because
field processing order depends of the iteration order of a `dict` (which
is undefined in python).
The testing tour `widget_x2many` worked by chance until now.
Adapt the tour to save the participants before the messages.
When the user searches for date (or a datetime) in the search bar, the
suggested date can become completely wrong. For example, in the French
localization where the date format is DD/MM/YYYY, the system will search
for the date MM/DD/YYYY. This is even worse when the date is not fully
written: DD/MM could be converted to MM/DD/0000, which doesn't make any
sense. This is related to the moment issue
https://github.com/moment/moment/issues/1407.
The fix is to make sure that the input date has a correct format thanks
to `parse_value`. The latter converts the date into a fixed format.
Fixes#11876
opw-676604
autosize does not work correctly (it moves the screen in all directions
sometimes when the user press enter in the bottom of the screen in some
browser),
So, we decided to have our own version, because of course, we can do it better. A
few horrible hacks later, I proudly present you "autoresize" (it was
almost named "odooresize" but common sense prevailed).
As added benefits, it plays better with our web client, so when you open
a dialog in a modal for example, the autosize fields should have the
correct height automagically (or should I say 'odoomagically')
The test was not stable enough since listview editable and onchange
API changes.
+ Some step were wrong (test of the wrong element)
+ Minimize differences with enterprise version (so that the two tests
are testing the same things)
(backport of enterprise version)
Fix various problems with list view editable :
* Click outside which should discard/save the line in edition
* Warnings which should not appear when line is being discarded/saved
* JS test
+ JS code refactoring
Move the widget_x2many tour to web and call it from test_new_api as it needs
to be overrided for the new design, and it requires models and data from
test_new_api.
Clean other unnecessary stuff from web_tests, and thus remove the addon.
Adapt the Favorites menu so that addons appending stuff in it are compliant with
the enterprise edition.
Mainly, creation of dashboard.less from of dashboard.sass so that we can use mixins
defined in the web addon.
Some changes as well in the dashboard view to make it compliant with the enterprise
edition.
Use correct naming convention: classnames with underscores, less mixins with hyphens.
When a many2one field of a searchview was selected
by default, through a default_*_id within the context,
the many2one value name wasn't translated.
e.g. with Spanish loaded (and l10n_multilang installed),
translate a project.project name in Spanish.
Then, while being in Spanish, in the project.project kanban,
click on the Tasks link of a project (tareas),
then, notice the value of the project name in the
search bar.
opw-632818
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
previous commit broke some tests. The issue is that the search view
now avoid making requests if there is no action id. But this is an
assumption that tests use, so some slight adjustments have to be made.
Also, this is the moment to give properly the action id to the favorite
menu. Instead of bypassing its parent, it now receives the action id
from the search view.
The search view architecture allowed an 'invisible' attribute in fields. These fields were ignored for the autocompletion and did not appear in the interface. The goal was to allow default parameters to create facets, without displaying the field in the interface. Since that functionality is not used and the new search view does not support it right now, the tests can be removed.
When creating a new record in list editable, due to previous commit 6349048, the load_record was called twice and the first record of the current list view (self.dataset.index) was used to fill the new record.
With this, we make sure a new record is indeed created.
Fix the web test to have a default_get call in mock models and increase the number of default_get assertions (for creations in list editable, the default_get is then called twice, not optimal but due to the absence of distinction between empty datarecord and filled with default values).
Christophe Simonis