The method `read()` may be very slow when reading relational fields and
computed fields, because the computed fields can be computed on a recordset
that is larger than expected.
The issue occurs on model 'res.partner' when reading fields 'child_ids' and
'purchase_order_count', for instance. Suppose we read those two fields on a
partner with 1000 contacts. First, the one2many field is read from the
database and stored to the cache; the latter adds the value ids to the
prefetching of 'res.partner'. Then, the fields are fetched from the cache.
When 'purchase_order_count' is accessed on the partner, the field is computed
on all its children as well...
closesodoo/odoo#29867
Commit a07a076c45 restricts the prefetching to
`self` when accessing the fields to return. This is too restrictive, as it
cancels prefetching of secondary records in computed fields. In this commit we
limit the scope of the restriction to `self`'s model only; this fixes the
original issue without impacting other models.
closesodoo/odoo#30133
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.
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
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 a tracked field is modified, a mail.message is created.
When create is called its tries to fill missing values with "default
values".
It first tries to find the default values in the context, which may
occurs.
For example, modifying a tracked field on a subtask will add a key
"default_parent_id" in the context, which is the parent_id of the project.task.
Create will try to use "default_parent_id" for the mail.message
parent_id field, which make the SQL Request invalid.
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
This reverts commit 2054b59285 which
already has been fixed multiple times [0].
However this change does not correctly handle successive onchange calls on
ony2many fields which alter existing rows.
i.e., in saas~11.4, an onchange has been added on move lines [1] in
order to create and/or update lines containing taxes amounts.
However, with diff-only onchange, a second call to onchange will discard
changes made by a first one as nothing change between the 2 calls.
Scenario: On an existing account.move, add a new credit line with a tax set.
The first onchange will update the tax line with new amount. Add a
second line (with debit amount balanced). The onchange will not change
the tax line, resulting as it value being reset to initial value. As a
result, the move is not balanced and cannot be saved.
[0] cd2ccc4110, 5e58ac16c3, 07023137cd
[1] d49ab568a2
Since 2054b59 if we created a record in a many2many relationship of an
onchange, we would also possibly erreneously return the NewId.
The logic of convert_to_onchange of _RelationalMulti doesn't send back
the ID field (if the ID is needed, it is part of the command, not the
update/create dictionary values of a command) and this commit does the
same for the code changed in 2054b59.
This commit also adds a test for this fix, and a test for the regression
corrected with cd2ccc4110 reported in #25969
fix for https://github.com/odoo/odoo/commit/2054b5928#commitcomment-29837226closes#25984
Without the call to `super`, with at least two level off expected
onchange return data (eg. `invoice_lines.name`) we have an error in
python2, python3 python implementation of OrderedDict and possibly other
python implementation.
So this worked most often (with python3 CPython C implementation of
OrderedDict) by chance.
closes#25960
Christophe Simonis