Since multi-website, we COW (copy on write) views when editing a view on a
website.
This is causing 2 issues related to module install/update:
1. During a module install, when creating an inherited view, it will create
that view as expected on the generic tree.
But that generic tree may not be used on website(s). Indeed, if the view
was edited, we are now using a copy of the view instead of the original
XML view (with an xml_id).
That copied view won't get the new inherited view in its view tree.
Now, we correctly copy the new view under every specific view tree (if
exists).
2. During a module update, when updating a view, it will only update the view
having the xml_id, so the generic one.
But most of the time, the generic view is not used as it was usually COW'd
and the specific view now replace the generic one.
Now, we also apply the update on the COW'd view. Note that only unmodified
field will be updated, this behavior basically mimic the noupdate behavior
on view's ir.model.data.
Step to reproduce for bug 1:
- Install website_sale module
- Go to a product page and then enter edit mode
- Make a modification to trigger COW, eg edit the information area under the
price "30-day money-back guarantee".
- Now install website_sale_comparison module
- The product page won't have the comparison button as the comparison view
inheriting the product view was created on the generic tree and not copied
on the specific tree (COW'd before the comparison module install).
Step to reproduce for bug 2:
- Repeat first 3 steps of bug 1
- Now make a modification in a view from the XML file in
website_sale_comparison module and update the module
- Only the view with the xml_id is updated, not it's COW'd views. This mean
that only the generic view is updated and not the specific one(s) really
used on the website.
task-1920487
closesodoo/odoo#29956
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.
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
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
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.
Large diffs (specifically in x2many fields) cause performance issues. They
overload the web client, which considers all returned fields as dirty.
closesodoo/odoo#27941
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).
Romain Derie