If module A define an sql constraints and module B, which depends on
module A, override the sql constraint, we must ensure having only the
last definition in constraints list. Having the two versions in the list
makes the ORM continuously trying to drop the second version by the
first one, then recreate the second version, when performing operations
like an upgrade a module B.
An illustration of this is the login_key on res.users, which is unique
per login in base, but unique per (login, website) in website.
closesodoo/odoo#30334
Following commit 983c7e8152.
`_compute_display_name` is overridden in partner to force `show_adress` and some
other context variables to None. When those values are in the context, calling
`display_name` can give a different result than calling `name_get()[0][1]`.
This commit reverts the changes of the mentioned commit where the behavior is
actually different, that is, when `show_address` is in the context.
It also adds a comment on the `_compute_display_name` method to avoid further
mistakes.
closesodoo/odoo#29510
On a record with a large x2many, the web client does not load all the data of
the lines (because of paging). If a line is modified by an onchange, at some
point the client will determine whether lines are valid (all required fields
are provided). It is possible that the client cannot evaluate the validity of
the modified line because of missing fields. In order to avoid this situaion,
the server sends all fields on modified lines.
On a record with a large x2many, the web client does not load all the data of
the lines (because of paging). If a line is modified by an onchange, at some
point the client will determine whether lines are valid (all required fields
are provided). It is possible that the client cannot evaluate the validity of
the modified line because of missing fields. In order to avoid this situaion,
the server sends all fields on modified lines.
closesodoo/odoo#29177
Odoo no longer supports python 2, thus some of these helpers can and
have been replaced by python 3 built-ins, therefore there is no need for
them to stay defined.
The removed helpers are:
* izip, imap and ifilter
* unichr, text_type
* implements_to_string, implements_iterator
* string_types, integer_types
* to_native
The python 2 shims have also been removed, and only the python 3 helpers
have been kept, because they can still be usable (i.e. accepting
both bytes and str for functions that can only accept one of the two)
[REM] pyjsparser: remove PY3 shims
They're no longer necessary as Odoo doesn't officially support python 2
anymore.
closesodoo/odoo#28519
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
When changing the field `image` on `res.users`, the `write_date` of the user is
not updated because the field is inherited from `res.partner`.
Related to Issue : 1839603
For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.
Before this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>" # lost English version
After this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>" # write had no effect
>>> record.arch
"<h1>Title</h1>"
When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.
To update translations, the supported way is to go to the list of translations
and update them there.
Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True
If a field is callable, it should also be ignored, the same way than
translate=True fields
opw-1887162
closesodoo/odoo#31330
Large diffs (specifically in x2many fields) cause performance issues. They
overload the web client, which considers all returned fields as dirty.
closesodoo/odoo#27941
Do not propagate cache invalidations to other workers when changes must be
discarded, because of an import error or a dry run, which are both handled as
successful transactions.
Instead of returning False directly when comparing a non-model, return
NotImplemented that will trigger the __eq__ test from the other side.
This allows third party objects (for instance a serialization/deserialization
scheme) that cannot be a Model to be considered equal is some scenarios.
closesodoo/odoo#19977
In 7f29b31cf the modifed has been improved but there was a typo if a
column contained an uppercase letter (which happen easily with random
field name in Odoo Studio).
opw-1890248
closes#27546
With this commit, any *explicitly* related fields will be `readonly=True`
by default.
*Implicitly* related fields (i.e. _inherits fields) however will keep the
source field's `readonly` attribute.
The rationales behind this patch are:
* Enforce good practices, as the most common use-case for
related fields is the same as for compute fields: to read data.
* Avoid errors where some user saves a form view which contains
a related field that the user doesn't have write access to.
Purpose
=======
When several warnings are raised, in an onchange for example, the warning
messages and titles are concatenated on the dialog, even if they are
exactly the same.
Specification
=============
Don't concatenate warning messages if they are exactly the same.
Currently check_access_rule method checks for record rules and raises an error
if there are either missing ids (deleted records) or forbidden ids (records
hidden due to a record rule).
Purpose of this commit is to have a method allowing to filter a given recordset
and receive only valid records. Its implementation is basically a refactoring
of check_access_rule.
This commit is linked to task ID 1856417 and PR #26565.
A copy call cn be made with a specified value to an inherits value, e.g.:
self.env['product.product'].browse(42).copy({'product_tmpl_id': 1})
In such scenario, it is assumed the translations are already correct on the
specified related record and should not be used in the copy translation.
i.e. the translations of the product.template 1 must not be duplicated during
the copy call above
Same logic for One2many fields which should not recursively copy the
translations for user provided values
Closes#27108
When filling the results of a read_group using
_read_group_fill_temporal we were using the name of the field.
(https://github.com/odoo/odoo/commit/283c842289f1bc06bc30a877864e868127418e80)
But _read_group_format_result needs the name of the groupy which can
differ from the name of the field as groupby supports the following
syntax for dates `field:groupby`
This ultimately lead to a crash when trying to groupby multiple date
fields in a graph view.
Linked to Tasks : #1879604 and #1879168
This may be completely broken/wrong, but damn if it doesn't speed
import up (2mn to 30s, the main cost center goes back to updating
computed fields during/after creation fields).
Followup from the previous commit: before this, _write takes 32% of
total runtime, of which 13.7% is ultimately assignable to add_todo.
Turns out for the test case we mostly keep adding records to recorsets
where they're already present, so the 13.7% of runtime in add_todo are
mostly spent creating orderedsets (11.17) then converting those back
into recordsets (1.75%) with some time spent creating lists and
appending records (already present) in them.
Checking if the records are already present before merging them in
decreases add_todo's runtime cost to 0.5%, and ultimately _write to
20%.
As many of the ignorable calls were merging a singleton or an empty
recorset into the parent recordset, optimising for these cases was
added to BaseModel's <= and >=.
The method _read_group_fill_temporal did not support multiple levels of
groupby. Which meant that everytime you grouped by a date and by
something else you had a traceback.
Christophe Simonis