As a developer,
when you craft your records set manually,
and wrongly use the API and set something weird in `ids`,
something else than a tuple of integers,
`repr` should help you to understand you did something wrong.
e.g.
before
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner(1,)
```
after
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner'(1,)'
```
We could put an assert in `_browse` to make sure `ids`
is a tuple of integers, but this is considered a non-stable
change, as it will suddenly crashes when you will update
Odoo while it wasn't the case before.
closesodoo/odoo#118119
X-original-commit: f689c4f53fc4663b17c57bd1d704b9ffb9f11f8d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Recent Odoo versions require modern postgres (e.g. use of jsonb), the
`NULLS {FIRST | LAST}` clause was added in 8.3 so should be well
supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering
clauses can be quite useful especially when sorting `DESC`: `NULLS
FIRST` and `NULLS LAST` are literal positions so they put nulls at
that location regardless of sort order whereas the default Postgres
ordering is to consider nulls larger than every other value so they
appear first when sorting DESC, which is often undesirable (putting
nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and
consistently, also update `regex_order` to use named groups to make
the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS
LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST`
to correctly flip the original as `NULLS` clauses are not relative
to the sorting order (they put the `NULL`-valued records at the
specified location regardless). Therefore apply `reverse_direction`
to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the
clause through the join would yield unexpected and illogical results
when mixing NULL m2o fields and non-NULL m2o fields with NULL
`_order` fields (as they would get mixed rather than clearly layered
/ separated).
However because SQL booleans are ordered the usual way (`true >
false`) the `NULLS` clause is fundamentally equivalent to sorting on
the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So
we can prepend the expanded m2o's ordering with such a clause to get
the correct behavior.
Replaces #116464
Supersedes #116664closesodoo/odoo#117439
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Petar Najman <petar.najman@modoolar.com>
As we have a team dedicated to work on analysing tracebacks
with sentry, and to takedown all tracebacks occuring on the saas,
we do an effort to avoid unecessary warnings and tracebacks
for both sentry and the runbot.
closesodoo/odoo#112101
Signed-off-by: Rémy Voet <ryv@odoo.com>
This fixes an issue with an override of onchange() on account.asset,
which asks for less fields to be considered in the snapshot. This also
guarantees that onchange() does not return values for unexpected fields.
Part-of: odoo/odoo#116779
after odoo #113888
when copy translations from one record to another, translations for
non-installed languages may raise error.
These translations may be
1. created before the langauge is deactivated
2. en_US which is always available for non falsy translated field value
this commit drops translations for uninstalled languages except 'en_US' when
copy and prevents raising error when users want to translate en_US when en_US is
not activated
closesodoo/odoo#115711
X-original-commit: 7bb1825ddbf2340882bef5ed1d9c877f78a2b815
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Purpose
=======
Allow to search properties fields.
For now, the properties fields are meant to be used with the frontend
top bar filter on views in a later commit, and so everything as been
kept as simple as possible for that particular use case.
Technical
=========
Relational properties
---------------------
We can not search on relational properties using the rec name, or
using one of their fields.
The following domains do not work
```
[('properties.partner_id', 'ilike', 'alice')]
[('properties.partner_ids', 'ilike', 'alice')]
[('properties.user_id.name', 'ilike', 'bob')]
[('properties.user_ids.name', 'ilike', 'bob')]
```
Instead, we should give the ids
```
[('properties.partner_id', '=', 55)]
[('properties.partner_ids', 'in', 55)]
```
IN operator
-----------
The "in" operator is used to either search specific tags / many2many
values, either doing a "OR like" condition on "non-array" value.
It can be used if the left or the right side is not an array
```
[('properties.my_char', 'in', ['a', 'b'])]
[('properties.my_tags', 'in', 'a')]
```
But it can't be used if both side of the condition are array, because
it will require to check type in SQL (which is technically possible,
but add extra complexity, so for now we keep the feature as simple as
possible).
So the following domain is not supported.
```
[('properties.my_tags', 'in', ['a', 'b'])]
```
Instead we should use the "OR" operator
```
['|', ('properties.my_tags', 'in', 'a'), ('properties.my_tags', 'in', 'b')]
```
Tags / many2many - "=" operator
-------------------------------
Tags and many2many have to be searched using the "in" operator.
So the following domain will return unexpected results and raise a warning.
```
[('attributes.mytags', '=', ['a', 'b'])]
```
The reason is that we don't want to dynamically check the type in SQL,
and so we need the "in" domain operator to know what to do in SQL.
Task-2980121
Part-of: odoo/odoo#101901
Purpose
=======
Do not modify the cache in order to improve the performance when we
read in batch. Instead we create a new batched method "convert_to_read"
that check existence in batch, and generate a dict with the result.
Now, all the properties field checks (many2one existence, selection option
still exists, tag value stiff exist, etc) and done in "convert_to_read".
It means that doing `record.properties` won't do all those checks.
Having the batched field fetch at the convert_to_record required too
many changes for the scope of this task, so "record.properties" having
the cache values unchecked is an acceptable tradeoff currently, hence
we batch convert_to_read.
Task-2980121
Part-of: odoo/odoo#101901
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Goal: make _search() always return a Query object, in order to make
search_read() in a single query when possible
Adapt the overrides of _search() towards the given goal.
Part-of: odoo/odoo#112126
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
A set iteration was creating a random number of queries on some tests.
This was noticed in TestEventPerformance were a random additionnal query
could appear in default_get depending on _get_description and
_get_default_stage_id order.
This commit uses a list to get a deterministic order. It looks like
the set was not useful anyway.
closesodoo/odoo#113563
X-original-commit: 13572df256ccc6351588851d385c381ace155e0d
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce:
- Make sure language preference is 'en_US'
- In accounting, in the dashboard click on bills
- Filter 'due_date' by week
Issue: The start day is Monday and should be, for 'en_US', Sunday as it
is the case in the dashboard view in accounting (see appendix).
Cause: The query uses the `date_trunc('week', date)` which in Postgres
retrieves the first day of the week as Monday (ISO week).
Solution: Create an offset in the query depending on the first day of
the locale variable.
Note: the `web/tests/test_read_progress_bar.py` has been modified: since
the default language is 'en_US' there will be an offset of one day. To
make it less confusing, I used only two anglo-saxons countries so the
day offset is not the variable tested. (for this matter, pleaser refer
to `test_read_group/tests/test_read_group_process_groupby.py`)
Appendix:
Language (english-US)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W23 -> 06/05 | 05/29 -> 06/04
W24 06/06 -> 06/12 | 06/05 -> 06/11
W25 06/13 -> | 06/12 -> 06/18
(Monday - Sunday) (Sunday - Saturday)
Language (french-BE)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W22 -> 06/05 | 05/30 -> 06/05
W23 06/06 -> 06/12 | 06/06 -> 06/12
W24 06/13 -> | 06/13 -> 06/19
(Monday - Sunday) (Monday - Sunday)
opw-2747066
closesodoo/odoo#93053
Related: odoo/enterprise#29539
Signed-off-by: Raphael Collet <rco@odoo.com>
The field is updated in SQL but not in cache. Also remove hacks in the
business code to prevent potential issues from this behavior.
closesodoo/odoo#113119
X-original-commit: 8bb660c985c7a1349cae1bf58dc5bf7981bd9058
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Consider field F in module X with parameter translate=False, and F is
overridden in module Y with parameter translate=True. During the
upgrade of module X, module Y hasn't been loaded yet, and the ORM
considers the field to be `translate=False`. Therefore it converts its
database column from type jsonb to varchar, and accidentally drops
non-en_US values:
{"en_US": "English value", "fr_FR": "French value"} (jsonb)
-> 'English value' (varchar)
As a result, translations are lost after upgrade.
This commit fixes the bug by checking whether the field is translated in
database and patches the field accordingly when loading the registry.
This avoids the ORM considering the field as non-translated while
upgrading modules.
In order to "force" translated fields to become non-translated ones, at
the end of the loading process the patch above is discarded, and fields
are checked again. We then adapt the schema of models that have such
fields. This extra step handles the uninstallation of modules like
module Y in the example above.
The patching of the fields has one potential issue. While upgrading
module X, field F is patched with translate=True. If module Y actually
overrides F with translate=xml_translate or so, this may cause the
behavior of the upgrade to be slightly incorrect. Because of the
complexity, we have chosen to not support this case.
closesodoo/odoo#112223
X-original-commit: 1e6e482a9763baa5fae70d9b6676d16a46458f4a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The class is a simple extension of dict, and adds an explicit attribute
for the content of the root node of a tree. It makes the code much more
readable with very small performance overhead.
closesodoo/odoo#111946
X-original-commit: 8a01d74e5f7d035cfd05bc02596f075270e0fcf8
Signed-off-by: Raphael Collet <rco@odoo.com>
Those APIs are aimed at hiding the implementation of trigger trees,
dependent fields and fields modifying relations. Explicit APIs simplify
the profiling of executions and comparison of implementations for
building trigger trees.
X-original-commit: d12b9270375634e738f5288d0c523ac0eec2fa18
Part-of: odoo/odoo#111946
Before this commit, there is no way to "void" model translations, i.e.,
discard a translation and let the value fall back on the 'en_US' value.
The API of methods write() and update_field_translations() can only
overwrite the translations for the specified languages.
After this commit, calling update_field_translations() with a falsy
value except the empty string discards the corresponding translation
value, and let the value of the field in the given language fall back on
the 'en_US' value of the field.
X-original-commit: 5434fb845c393327db377abf872c448f4860a7d3
Part-of: odoo/odoo#111869
model/model_terms translations:
A transifex link if available is displayed after the language in the translation
dialog to help translators to contribute their translations. The tooltip message
for mouse hovering is 'Contribute'
code translations:
Setting -> Translations -> Application Terms -> Transifex Code Translations
In order to reuse the list view and search bar, model transifex.code.translation
is created to store all code translations.
This model is
1. readonly
2. reloaded on demand/by cron(7 days) to avoid increasing the Odoo restart time
3. updated for new installed modules/languages while opening the list view
4. shared to all users without duplicated translations
closesodoo/odoo#111685
X-original-commit: 7b30badb52e2a948c41f4340a01f6118818c6711
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
Warn when constrains name combine with table name will be more than
63 characters.
This is to avoid case like the one fixed in #103148
Unlike index, since constrains name are defined in the code, we prefer
to avoid automatic truncate and add a warning since devs can chose
an appropriate short-enough name.
The linked fixes will just truncate the name to the max length
to match the name in existing databases. Renaming could be done in other
pull requests with upgrade scripts to avoid constrains re-computation.
Part-of: odoo/odoo#109065
The revision 65a012c2bba0ed81d9b525a7779c726043b17707 changed the
behavior of method _read() when invoked on a record with id None.
Before the change, the method would consider that no records have been
fetched because the id is falsy. After the change, it keeps the id None
in the fetched records, and attempts to make subsequent SQL queries like
"column IN ()", which is syntactically incorrect.
OPW 3104957
closesodoo/odoo#108785
X-original-commit: 712d03cb2ee5f2fde0e80619be5db38aa09ed1ac
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
This is a rare case where method _read() raises a MissingError instead
of just ignoring it.
The issue is triggered by several conditions on a model M:
- at least one ir.rule on M with a domain using a column field on M;
- one deleted record Y which is in the prefetch set of a record X;
- one reads a non-column field on record X.
Fix method _read() to manage that case. It adds an extra call to
exists() in that case, but adds no overhead in the general case.
closesodoo/odoo#108050
X-original-commit: 1876dc87e5c88c711c9b3882c39be704ffc46532
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
The model terms translations assume the number of terms in each language of a
model_term translated field should be the same.
However, sometimes the assumption cannot be promised for sake of bad
translations
This commit
1. drops illegal model term translations while translating
2. drops mismatched terms at run-time in case the database has been contaminated
closesodoo/odoo#107373
X-original-commit: f9ab5ca3e99b2883ada18a8f6deb12d45608b43f
Signed-off-by: Raphael Collet <rco@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Sometimes a constraint is too complex to be expressed in the general
`_sql_contraint`.
This allows to hook on a constraint if it matches the name in order to
display a user friendly error message.
X-original-commit: e1f06479a526c703ccabc441b1e194646206b966
Part-of: odoo/odoo#106325
The mapped call is supposed to populate the cache, but that's already
taking care of by prefetching. It ends up adding an overhead instead.
The perf improvement is more noticeable on large recordsets.
For example, on a database populated with 100k res.partner records.
Before:
.. code-block:: python
partners = env["res.partner"].search([])
partners.filtered("name") # warm up
timeit.timeit(lambda: partners.filtered("name"), number=10)
# result: 7.15
After:
.. code-block:: python
partners = env["res.partner"].search([])
partners.filtered("name") # warm up
timeit.timeit(lambda: partners.filtered("name"), number=10)
# result: 4.67
closesodoo/odoo#105350
Signed-off-by: Rémy Voet <ryv@odoo.com>
O2MIdMapper Class inherit of 'base' Model to change the behavior of
`create`.
Because it is in base and the `_import_current_module` is set in
models.py, move it at the end of create in models.py.
closesodoo/odoo#99550
Related: odoo/enterprise#33063
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
In the PR #97692, writing empty str `''` to a model term field no longer removes
all translations. Instead, only the translation for the current language is set
to empty str `''`.
Before this fix, if a web user sets a translation to emtpy str, and reopens
the translation dialog, the translation will be reverted to the 'en_US' value
which is wrong.
closesodoo/odoo#104181
X-original-commit: f97ff6308d472121e65a34d30b4dc5ab35065220
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
When looking to fetch grouped data from the database, `read_group`
should work(-ish), especially with support for `array_agg`. This also
means this need should be more or less solved around RPC: client can
either `read_group` or group on the client side.
This leaves a glaring hole in the fabric: there's no convenient tools
to apply grouping to recordsets. `itertools.groupby` exists, but it
requires that the input be grouped by the key function, and it yields
an iterable of items which is not the most convenient for recordsets.
This here utility:
- is exclusive to recordsets
- returns a mapping of grouping keys to subsets of the input recordset
- keeps the prefetching of the source recordset
- allows grouping on a field, or an arbitrary (callable) key
- should work even on "new records" (aka should be suitable for
onchanges / arbitrary compute functions)
While the method is RPC-compatible, it's not especially designed for
that, it is likely a much better idea for the client to `read` the
data they need then group that client side on whatever criteria they
are interested in, or `read_group` the aggregated information they
need directly if that's an option.
Part-of: odoo/odoo#101522
* clean and improve docstrings in orm
* fix typos found with codespell
* rely on the Environment class docstring instead of doc content (and
therefore move part of the doc inside the class docstring)
closesodoo/odoo#102969
X-original-commit: 8250cd4b210005d223a4cdb8afa4014425ca6fa3
Related: odoo/documentation#2803
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Purpose
=======
Check the existence of the relational properties (many2one / many2many)
in batch and prefetch the values in batch as well to reduce the number
of SQL queries.
Technical
=========
The existence is checked in the read method of the properties field,
because we have the entire recordset. Then, the non-existing ids are
remove from the properties values and the cache is updated.
Task-2965523
X-original-commit: dba9b684d29c0041a32a5508284573851b8dd097
Part-of: odoo/odoo#102243
By definition, views are useless without the web client.
The web client is in the module `web`.
Therefore, in a perfect world, the `get_views` model method
and any related method should be within the `web` module,
as without it they are useless.
Let's imagine you would like to use fully in command-line,
without web client, all those view related methods are useless.
Maybe excepted for reports, as you might still like to be
able to print reports while using odoo fully in command line.
Views related method therefore shouldn't be in `odoo/models.py`.
Also, when you think about it, `get_views` related methods do not
make sense without the model `ir.ui.view`, which is loaded after
the `get_views` related methods, which also doesn't make sense.
However, moving these methods fully in the `web` module is an harder
work. For instance, there are base models, such as res.partner,
already overriding `get_view` in the `base` module,
and therefore relying on these view related methods.
As a first step, we move view related methods direcly in the
`odoo/addons/base/models/ir_ui_view.py` file, where
the `ir.ui.view` model is loaded.
This is not only a design / cleaning change,
but a required change to be able to use content of
`odoo.tools.config`, which is loaded after `odoo/models.py`.
For instance, if you want to configure a conditional decorator based on
the config `odoo.tools.config['dev_mode']`, it is not possible
to do so in `odoo/models.py` because the config is parsed/loaded
after `odoo/models.py`.
The config is loaded here:
https://github.com/odoo/odoo/blob/31de2b0a7a0921cab3c6c54045d15da46c8e6d8a/odoo/cli/server.py#L127
While, within the same file, `odoo/models.py` gets loaded through the
`import odoo`
https://github.com/odoo/odoo/blob/31de2b0a7a0921cab3c6c54045d15da46c8e6d8a/odoo/cli/server.py#L26
And we would like to put such a decorator based on `odoo.tools.config['dev_mode']`
on `_get_view_cache`, to not cache the back-end views when `--dev xml` is
passed in the server arguments.
X-original-commit: 0901adc38a724aec75676285977f1905a84ed8ee
Part-of: odoo/odoo#102117
Bug
===
- create a new helpdesk ticket without properties
- create a new property
- change the customer
=> The added property is removed
The fix in the onchange of models.py needs to be more specific, and
should be used only when the definition record is changed.
Task-2965523
X-original-commit: 909ee004183068d9ffa94abe0d1472a8f0534f34
Part-of: odoo/odoo#101487
The cache currectly fails to correctly invalidate relational fields that depend
on a non-relational field. Two passes of invalidation are done, to reflect
dependencies on both the old and the new written values. In the first pass
only relational fields are considered, as explained in the comments:
> It is best explained with a simple example: consider two sales orders SO1 and
SO2. The computed total amount on sales orders indirectly depends on the
many2one field 'order_id' linking lines to their sales order. Now consider the
following code:
>
> line = so1.line_ids[0] # pick a line from SO1
> line.order_id = so2 # move the line to SO2
>
> In this situation, the total amount must be recomputed on *both* sales order:
the line's order before the modification, and the line's order after the
modification.
The written values can be seen as the roots of a dependency forest (a
collection of dependency trees). Before this commit all non-relational roots
and their corresponding trees were filtered out during the first pass. However,
this approach is wrong, as relational fields can also depend on non-relational
fields. Instead, the complete dependency forest has to be traversed, skipping
invalidation for non-relational fields during the first pass.
The test that was previously included accidentally succeeded because of a
separate and unrelated bug in the orm domain parser: in certain one2many or
many2many leafs the domain parser would not take into consideration the domain
included in the definition of the field. As a result, the test still passed
by accident, because the records that no longer matched the domain after the
write were still invalidated during the second pass.
The problem can clearly be demonstrated, however, when the dependency is
generated by a compute function.
closesodoo/odoo#101038
X-original-commit: d4a5827b42d80f0f830455dcd2056701eb09aed1
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
- In `unlink`, since https://github.com/odoo/odoo/pull/66938
modified is called on self for each batch of 1_000.
But it should be called on the batched records.
- In `write`, remove useless `records_to_inverse`
(there from ORM refactor but never used)
- make `_modified_triggers` more deterministic by
changing a `set` into `OrderedSet`.
closesodoo/odoo#100472
Signed-off-by: Raphael Collet <rco@odoo.com>
A feature allows to set the modifiers invisible, readonly, required
according to a key in the context
e.g.
```xml
<field name="date_approve" invisible="context.get('quotation_only', False)" optional="show"/>
```
Following odoo/odoo#99417,
back-end views are now cached.
These expressions are currently evaluated server-side,
before serving the view to the web client.
Hence, the modifier becomes for instance `invisible="1"` or `invisible="0"`
according to the context passed when calling `get_view`.
The key used to cache the views doesn't take into account such context keys.
Hence, when you asked for a view using for instance
`invisible="context.get('quotation_only')"`
A first time using the context `{'quotation_only': True}`
and a second time using the context `{'quotation_only': False}`,
on the second time, you received the view from the first time you
requested the view, where the modifier is evaluated as if the the
context was `{'quotation_only': True}`.
As we do not want to store a cached version of the view for each
possible key in the context, postprocess the evaluation of the
modifiers using the context after retrieving the view from the cache.
A better alternative would be to delegate this evaluation to the
web client, because it already has the information it needs,
it has the context value.
Modifiers using domains are already evaluated client-side,
it would make sense modifiers using context would too.
Nevertheless, as this bug has been introduced by odoo/odoo#99417,
and as we are close to the release, solve this server-side,
to keep a similar behavior than before.
We might re-consider the implementation of this later on.
closesodoo/odoo#100130
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Oversight in odoo/odoo#100376
The web client sends `list` rather than `tree` when requesting
views.
However, once they went through `get_views`, they are converted back
to `tree`.
https://github.com/odoo/odoo/blob/master/odoo/models.py#L1653
So, here, we should check against `tree`, not `list`.
Could be seen in Lunch > Manager > Today's Order.
With the `id` field missing, an error is raised
```
Uncaught (in promise) Error: The following error occurred in onWillStart: "field is undefined"
```
closesodoo/odoo#100474
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Denis Ledoux