[18.0][MIG] base product mass addition #2150
Conversation
…ss to product.product may still use the feature
…TBD in another PR
Currently translated at 7.1% (1 of 14 strings) Translation: product-attribute-14.0/product-attribute-14.0-base_product_mass_addition Translate-URL: https://translation.odoo-community.org/projects/product-attribute-14-0/product-attribute-14-0-base_product_mass_addition/fr/
Currently translated at 71.4% (10 of 14 strings) Translation: product-attribute-14.0/product-attribute-14.0-base_product_mass_addition Translate-URL: https://translation.odoo-community.org/projects/product-attribute-14-0/product-attribute-14-0-base_product_mass_addition/fr/
Supress LOG_ACCESS_COLUMNS writes if we're only writing on quick magic fields, as they could lead to concurrency issues. Moreover, from a functional perspective, these magic fields aren't really modifying the product's data so it doesn't make sense to update its metadata. We achieve it by reverting the changes made by ``write`` [^1], before [^2] reaching any explicit flush [^3] or inverse computation [^4]. [^1]: https://github.com/odoo/odoo/blob/f74434c6f/odoo/models.py#L3652-L3663 [^2]: https://github.com/odoo/odoo/blob/f74434c6f/odoo/models.py#L3686 [^3]: https://github.com/odoo/odoo/blob/f74434c6f/odoo/models.py#L3689 [^4]: https://github.com/odoo/odoo/blob/f74434c6f/odoo/models.py#L3703 Basically, if all we're modifying are quick magic fields, and we don't have any other column to flush besides the LOG_ACCESS_COLUMNS, clear it.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: product-attribute-15.0/product-attribute-15.0-base_product_mass_addition Translate-URL: https://translation.odoo-community.org/projects/product-attribute-15-0/product-attribute-15-0-base_product_mass_addition/
Currently translated at 100.0% (10 of 10 strings) Translation: product-attribute-15.0/product-attribute-15.0-base_product_mass_addition Translate-URL: https://translation.odoo-community.org/projects/product-attribute-15-0/product-attribute-15-0-base_product_mass_addition/es/
Currently translated at 100.0% (10 of 10 strings) Translation: product-attribute-15.0/product-attribute-15.0-base_product_mass_addition Translate-URL: https://translation.odoo-community.org/projects/product-attribute-15-0/product-attribute-15-0-base_product_mass_addition/it/
[REF] Remove call to flush that are obsolete, in tests.
… the same way, to remove the errror : 'UserWarning: Field product.product.quick_uom_id in dependency of product.product.quick_uom_category_id should be searchable. This is necessary to determine which records to recompute when uom.uom.category_id is modified. You should either make the field searchable, or simplify the field dependency. '
bealdav
force-pushed
the
18.0-mig-base_product_mass_addition
branch
from
fed3180 to
3c4d0d9
Compare
bealdav
force-pushed
the
18.0-mig-base_product_mass_addition
branch
from
3c4d0d9 to
f03e64c
Compare
| # Case 1: Updating qty_to_process shouldn't write on products | ||
| self.product.qty_to_process = 4.0 | ||
| self.env["product.product"].flush_model() | ||
| self.assertEqual(base_date, self.product.write_date) |
There was a problem hiding this comment.
Hi @ivantodorovich I can't understand how to make it works.
I tried some things, by no way.
Do you think you can have look here ?
I'm not familiar with cache management even if I dived in for the circumstance.
Thanks a lot.
There was a problem hiding this comment.
Hello @bealdav !
Ouch, this was a nightmare.. 😓
Essentially this is what's implemented in the modified override, and what's described in the comment there:
# OVERRIDE to supress LOG_ACCESS_COLUMNS writes if we're only writing on quick
# magic fields, as they could lead to concurrency issues.
#
# Moreover, from a functional perspective, these magic fields aren't really
# modifying the product's data so it doesn't make sense to update its metadata.
#
# Basically, if all we're modifying are quick magic fields, and we don't have
# any other column to flush besides the LOG_ACCESS_COLUMNS, clear it.
I don't see any immediate reason why this would stop working 18.0.
Since this is low-level, I would also doubt the unit tests, so maybe perform a manual test: adding a product from the sale quick view, and verifying that the product's write_date didn't change.
You can also set a breakpoint in the modified override and inspect if there other fnames besides the qty_to_process, quick_uom_id or any of LOG_ACCESS_COLUMNS when using the quick addition. Normally there shouldn't be any
There was a problem hiding this comment.
Hi @ivantodorovich thanks for your answer.
I 've done these checks. I really understand it should be a nightmare ;-)
I ask myself if can only remove write_date from vals ,overriding write when no other fields than qty_to_process, quick_uom_id or any of LOG_ACCESS_COLUMNS are present ?
Do you approve this strategy ?
There was a problem hiding this comment.
🤔 I'm not sure, cause these LOG_ACCESS_COLUMNS are also set at the very last step, during _write: https://github.com/odoo/odoo/blob/39b969de4cae74a3298b415f6cad9693922b3386/odoo/models.py#L4875
So even if you're able to catch the ones set by write (https://github.com/odoo/odoo/blob/39b969de4cae74a3298b415f6cad9693922b3386/odoo/models.py#L4730-L4732), it's likely not enough
Maybe a completely different approach would be to implement the sale order update mechanism in a write override that doesn't call super when only these fields are written -- then we wouldn't need to deal with cache or anything
12 participants
No description provided.