The mock server's mockReadGroup function would not properly compute the
value, range and domain of the returned groups for date/datetime fields.
The value should be expressed in the local timezone,
and the range/domain shoulb be expressed in UTC timezone.
Consider the following:
- a record with a datetime field of value "2016-12-14 12:34:56" (expressed in UTC)
- a user with an UTC+2 timezone offset
- a read_group with groupby "['datetime:hour']"
The corresponding group would have had the following metadata:
- value: `"12:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 11:00:00"], ["datetime", "<", "2022-12-14 12:00:00"]]`
- range: `{ from: "2022-12-14 11:00:00", to: "2022-12-14 12:00:00" }`
It now has the following valid metadata:
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 12:00:00"], ["datetime", "<", "2022-12-14 13:00:00"]]`
- range: `{ from: "2022-12-14 12:00:00", to: "2022-12-14 13:00:00" }`
closesodoo/odoo#96946
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, an error was raised when an invisible button was
found on a list view (for example, if it has a group).
Now, the invisible buttons are correctly managed.
closesodoo/odoo#96963
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a ListView, a field containing an invisible
attribute using an expression to be evaluated was never displayed.
Example:
<tree>
<field name="foo" invisible="context.get('notInvisible')"/>
</tree>
The foo column is never displayed.
The solution is to use the column_invisible modifier to know if the
column should be displayed or not. column_invisible contains the
evaluated expression of the invisible attribute by the server.
closesodoo/odoo#97066
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Doing a `search_count` on millions of records could be very slow. On
large databases, the pager counter "1-80 / 8000000" could take several
seconds just to get the total number of records.
This commit limits the counter in list and kanban views to 10k records,
and shows "1-80 / 10000+" if the limit is reached. If you click on
10000+, it updates with the real count (or if you go up to 10000 with
pager or input value).
The search_count on res.partner of odoo.com takes 4s. With this patch,
it will take ~20ms.
Task 2761165
closesodoo/odoo#95642
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The call to web_read_group done in _loadGroups was incorrect when the first groupby
was of the form date_field:granularity (e.g. "create_date:day"). The groupby was
sent as a mesure and interpreded as such, leading to an error of the form
"Invalid aggregation function ...".
This was not detected before by lack of manual testing: the mock server used in tests
checks the read group parameters in a different way from what is done server side.
So the error was not visible in the testing environment.
In this commit, we remove the error in web_read_group and improve the mock server
(a bit) so as to make such errors be detected.
Part-of: odoo/odoo#92475
This commit introduces the new kanban, list and form views written
in owl. Even though it contains the implementation of those 3 views,
only the kanban view is activated for now (the list and form views
aren't 100% ready yet, so they aren't added to the view registry).
Alongside the views, the fields (<field name="..."/> in archs) and
widgets (<widget name="..." in archs) of web/ have been implemented
in owl as well. Legacy ones remaining in other addons are supported
in our new views, thanks to a compatibility layer. The goal is to convert
them asap though.
Legacy views, fields and widgets are kept for now, which explains the
number of added lines in this PR (around half of them concern tests).
They are still extended by custom code in other addons, that still need
to be converted (a lot of them are already on the way). Moreover,
they are still used in Studio as well. The plan is to lazy load them in
the Studio bundle when all custom code extending them will be
converted. Studio will be converted for v17.
Part-of: odoo/odoo#92475
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
The mock implementation of search_count returns `false` instead of 0 when the
domain doesn't match any records.
Also, writing some tests revealed the `active_test` context key was not taken
into account.
closesodoo/odoo#93746
Related: odoo/enterprise#28449
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since 43474916 and ff37a2fe, the function `name_get` now returns an
empty string for missing records. This change was not reflected in
mockServer.
This commit also copies the tests of `name_get` on the legacy mockServer
to the "new" one. They were missing.
closesodoo/odoo#92473
X-original-commit: 638fab65cdf7a615138dee1395f54224b3ea1e77
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
odoo/odoo#87522 introduced the concept to automatically
inline tree, kanban and form views under one2many/many2many fields
within form views.
The goal being for the web client to make less `get_views` calls.
However, currently, automatically inlined form views
under one2many/many2many fields leads
to more triggered onchanges than before,
triggering more field computations than before,
potentially leading to performance issues
as more fields are computed than before.
Besides, they are not visible in the tree/kanban view
and their computation can therefore be considered useless.
At worst, it can even causes bugs, by triggering computation
in places they were not used / do not handle correctly,
as explained in
https://github.com/odoo/odoo/pull/87522#issuecomment-1132554918odoo/odoo#91878
This revision reverts the behavior to automatically inline
form views, while keeping the inlining of kanban/tree views.
However, by reverting this, we re-introduce a limitation
of the web client behavior regarding onchanges,
explained in odoo/odoo#91935.
This is therefore not perfect,
but at least the previous behavior is back.
In the future, work will be done to re-introduce the automatically
inlined form view, while solving both issues:
- Do not trigger more onchanges than necessary,
- Solve the limitation of the web client shown in odoo/odoo#91935closesodoo/odoo#91968
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Now that pyEnv is available, using it in the mock_server lighten the syntax.
task-2582313
closesodoo/odoo#90783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit orders the records coming from the mock server the same
way they are ordered by the ORM, while also allowing it to support
multiple levels of orderby.
This has been done to increase consistency in the test suite and provide
a more accurate representation of how records would be returned by the
actual server.
Some tests performed their assertions based on this previous
undeterministic system and have been adapted, either by altering
the base setup or the assertions themselves.
closesodoo/odoo#84718
Related: odoo/enterprise#24509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The mockSearch function should not return the list of records for a
domain and a model but the list of ids.
The path "/web/dataset/search" does not exist.
closesodoo/odoo#80835
X-original-commit: 5f6d72e43eaec803eea76927433706dfd5e2be73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit 0134495ba5 the reporting
views pivot, graph, cohort are written in full new framework.
Some applications still need the legacy ones, so this commit just implements
the lazy loading of those views.
In stock, report_stock_forecasted has been adapted in order to avoid having
a GraphView override: we now modify the canvas' height in pure JS.
*: board, stock
closesodoo/odoo#76931
Related: odoo/enterprise#21054
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We refactor the action service and allow the legacy and new views to share
a global state within a same action.
We introduce two new components View and WithSearch along with
the search infrastructure: ControlPanel, FilterMenu,...
Part-of: odoo/odoo#73311
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
On 00e3cb74c4 the migration of the code to
parse and formate dates on the mock server from moment to luxon was
done. Two issues were introduced on that commit: Parsing a date
displayed on quarter wasn't possible; And the ISO week year wasn't used
to format the date, but it was used to parse the date, for symmetry's
sake, now the ISO week year is used on both.
closesodoo/odoo#75354
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
* Add test name when logging missing action ids, makes finding out
which test causes the issue much simpler.
* Suppress the warning emission in the one remaining test which
triggers it, as testing invalid action IDs is exactly the purpose of
the test.
Two internal warnings are features which literally are not (entirely)
implemented, the tests can't be fixed to avoid them. Also augmented
the log messages with which test triggered the log, as it's very hard
to debug the issue otherwise.
As for the qweb debug mode warning, there's no way to disable it
easily because multiple tours explicitly opt into debug mode (with
good reasons), so it's not enough to just bypass the `mode` setter in
the test setup helpers (test_main in POS and main_tests in web), there
would also need to be special workarounds in the 4 modules which set
`owl.config.mode` based on the session's debug mode.
I don't know that this warning is even useful, it defaults to `false`
so the only situation in which this would be relevant would be for a
third-party to use Owl *and* explicitly enable the debug mode *and*
forget to remove it when deploying to production *and* look at their
console.
Before this commit, the "Edit View" debug item only worked for
kanban, list and form views. For the other views, it opened a
blank form view. The reason is that for the other views, it didn't
correctly get the id of the view to edit.
Bug reported in the wowl-bugs pad
closesodoo/odoo#72523
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the new mockServer, we add a name to a view (field name on ir.ui.view) when the found view in `fieldsViewGet`
has an id.
In tests data, one would normally specify default views like
```js
views = {
"partner,false,form": `<form></form>`,
}
```
In this case and from the point of view of the business code, the view doesn't really exist in DB
On the contrary, if a developer writes, in a test:
```js
views = {
"partner,999,form": `<form></form>`,
}
```
The returned view from load_views will return that view with ID 999 and, from the business code standpoint, the view would exist
in DB. This is particularly important in studio when it has to fetch a x2m view when none has been inlined in the main view.
This commit is the first phase of the conversion of the web/ JS
codebase to the owl framework. The impact of this commit is two-fold.
First, it rewrites the framework part of web with a new system of
services and registries. Services allow to execute code (e.g. do rpcs,
setup things) before launching the application. They can also expose
an API to be used by other parts of the application (e.g. a notification
service would expose a function to display notifications). Services are
often a good extension point for external modules that want to execute
code at webclient startup. Registries offer another way to extend the
application. They provide well designed extension points to add
elements/behaviors from the outside (for instance, to add a systray item,
an error handler...).
Second, this commit initiates the conversion of the webclient to owl
with a top-down approach, around those notions of services and registries.
The root of the web application is now an owl application. Among others,
the WebClient, ActionManager, Navbar, UserMenu, DebugManager, Dialogs,
services (e.g. notification, ajax...) have been converted to the new
framework/architecture.
Legacy views and client actions are still supported (and used). They
will be converted in the next months, and at some point, the support
will be dropped.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).
We deal with extreme cases (when the widget is, by mistake, set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.
Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.
This commit ensures that we keep in the relation all values that
aren't displayed.
Issue spotted when working on opw~2439041
closesodoo/odoo#67400
X-original-commit: 9e9d3aa78c42ad4ffca3b56a28382ed84078cde3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The support for "active_test" context key has been introduced in c2918c1
However, the context key is ignored in many mocked ORM methods (if not all).
This commit adds support for the `search` and `search_read` methods.
Note: this is done to easily write some tests in odoo/enterprise#16363
and it might be usefull to test futures features (or fixes) using this
context key.
closesodoo/odoo#66393
X-original-commit: 0ad1c1631eb233b3e8f98b40f8c0813d0ad7acbe
Related: odoo/enterprise#16447
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The mock implementation of `name_get` does not fully reflect
the real server implementation.
The real implementation is described in tests added in
this commit.
Note: in my wildest dreams, the mock server tests would be run
against the real *and* the mock implementation to ensure they
do not diverge.
closesodoo/odoo#62430
X-original-commit: c8f59bfd5c8ddb7c7abf1108111507e667393208
Related: odoo/enterprise#15017
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The mock server was slicing the records before sorting.
Now mocking a search read would sort the records before slicing them.
This will ensure the records to be loaded with the correct sorting order
when e.g. a load more is applied on a subset.
Taskid: 2196661
Also fix an issue with livechats not being considered in 'chat'
filter of messaging menu.
Task-Id 2282426
closesodoo/odoo#58468
X-original-commit: 631e52536964763bbfe857305f023e5e67084e95
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closesodoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit introduces a new semantics to define action and method buttons
in the list view.
The aim of this feature is to be able to do some actions on selected records, or on the entire
records' domain with the help of buttons located in the controlPanel, much like the form view header buttons.
To define such buttons, one must add a `header` node in the list view's xml definition
```
<tree>
<header>
<button type="action|object" name="actionId|methodName" string="button's text" context="{}"/>
</header>
<field name="fieldName" />
</tree>
```
task-2246383
The counters for categories were not updated when filter values were
selected. This commit fixes that situation.
This might impact the global performances of the search panel but
there is still room for improvement. Actually, it could be
possible to reload categories and filters less often by carefully
track the internal changes and the categories/filters attributes
(enable counters, expand,...).
closesodoo/odoo#49307
Related: odoo/enterprise#9795
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the search panel, the domain used to compute the field image values
(when the attribute expand is false) was the same as the domain used
to compute counters (if enabled). The idea was that a value bringing an
empty domain is totally useless and should not displayed.
That being true, it turns out that if one does not allow them and
several fields are used, selecting a value in the search panel will very
often totally transform the search panel. From a UI perspective,
this turns out to be bad: the search panel 'moves'.
Let us give an example:
Let us start from a search panel that looks like to:
first_field
A 1
B 3
second_field
C 1
D 2 <--- mouse above D
E 1
with first_field and second_field both with expand="0" and
enable_counters="1". Let us also assume that no record in the global
domain has both first_field=A and second_field=D.
Click on D would make the search panel look like to something like
first_field
B 1
second_field
C 1
D 2
E 1 <--- mouse here
(the selection of D does not impact the values for the second_field but
does for the other first_field values).
This has led us to use basically only the domain comming from
outside of the search panel to compute field image values.
This means that we might now have value with zero count even if expand
is false. In the above situation, a click on D would give us
first_field
A
B 1
second_field
C 1
D 2 <--- mouse still above D
E 1
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.
Task ID: 2154749
The commit introduces two new attributes for search panel fields:
- hierarchize: boolean attribute (default True) available for
many2one fields with select="one". It allows to choose whether
to hierarchize the field values using the _parent_name (if set)
on the field comodel.
Note that a sanitization of the parent hierarchy takes place.
Basically, it ensures that parent chains are
completely in the domain (on comodel) accessible by the user.
See _search_panel_sanitized_parent_hierarchy documentation for
more information.
- expand: boolean attribute (default False) available for many2one
and many2many fields. If set to true, all field values are fetched
and displayed in the search panel. If set to false, only the
values that have at least one corresponding value in the field
model (and in some domain) are fetched.
An exception in the case of an hierarchized field
(hierarchize=True and _parent_name set): more/less values can be
displayed in order to have a good representation of the parent
hierarchy. That means we complete and sanitize the set of initial
field image values.
Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Before this commit, the mock server "_mockDefaultGet" method was a bit
naive:
- it accepted any 'default_' field coming from the 'kwargs.context'
regardless of the existence of the field
- it accepted any value for these fields
Now the method is looks a bit more like its original server-side
counterpart:
- the context keys are added if they correspond to actual fields
- a pseudo validation removes many2one fields values not corresponding
to any record
This commit introduces several changes in the search panel with
respect to record counts:
- the record counts are now also available for
the fields with select="one" attribute
(if not disabled explicitely).
- the record counts are better computed using the idea that
selected values within a group should not impact the counts
for the group values but only the counts for the other
group values.
On the way we have changed two keys in the values returned
by the server:
- 'count' becomes '__count'.
It has been done to avoid a possible clash in case a model would
have a field named 'count' and that the field values would be
wanted for some reason.
- 'name' (multi case) becomes 'display_name'.
It has been done in order to make the select one and multi cases
more similar and factorize some code.
TASK-ID: 2166814
Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
*google_drive
Go to a user form view and click on "Change Password" in the action
menus.
=> traceback `Cannot read property 'constructor' of undefined`
This error is raised because `active_domain: undefined` is in the context
and py_eval can't handle an undefined value.
closesodoo/odoo#48915
X-original-commit: 69694c627be42e3d068e48be14026493628a3a8d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Co-authored-by: aab-odoo <aab@odoo.com>
This commit allows the user to apply actions to all records
matching the current domain in list views. It also ensures that
the user is aware of the set of records actually selected.
The number of selected records is now displayed in the control
panel, and the user can, with an additional click, select all
records matching the current domain instead of the ones of the
current page.
Task 2185145
Before this commit, if the records had to be sorted according a
many2one field, and there was a sequence field on the many2one
comodel, the sequence was ignored. Now, the sequence is taken into
account like the actual server does.
Linked to odoo/enterprise/pull/7407
closesodoo/odoo#43763
X-original-commit: 714e52f98eec5c64a224523cee4b1e14463ed191
Related: odoo/enterprise#7869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bruno Boi