[19.0][MIG]: sale_order_secondary_unit#4175
Conversation
…dary product unit
…his module instead of product_secondary_unit
Added domain to limit `secondary_uom_id` to the one defined in product template
…prove inheritance). TT36255
As the test should only test that no change on the UoM quantity is done when modifying the secondary unit, we remember the existing quantity and compare it later with the final value, instead of testing against a fixed value, so any interaction with other modules don't interfere.
Currently translated at 100.0% (18 of 18 strings) Translation: sale-workflow-15.0/sale-workflow-15.0-sale_order_secondary_unit Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-15-0/sale-workflow-15-0-sale_order_secondary_unit/es/
Currently translated at 38.8% (7 of 18 strings) Translation: sale-workflow-15.0/sale-workflow-15.0-sale_order_secondary_unit Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-15-0/sale-workflow-15-0-sale_order_secondary_unit/fi/
- Include context keys for avoiding mail operations overhead.
…uom to variants TT45597
…ary_uom_qty is filled
…y quantity fields optional TT49686
Currently translated at 100.0% (18 of 18 strings) Translation: sale-workflow-17.0/sale-workflow-17.0-sale_order_secondary_unit Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-17-0/sale-workflow-17-0-sale_order_secondary_unit/it/
The behaviour of odoo in v17 when modifying an existing order line is to recalculate the price based on the price set on the product and not on the line. This module itself had an error in its tests as it was checking a price based on the modified price of the line (1000) which was not correct as when modifying any data of the order line the price was recalculated based on the price of the product which by default is 1 if it has not been set. TT54893
…creating product attributes It avoids the collision with the number_uniq constraint in product.attribute of the product_variant_default_code module, which applies uniqueness even on translated names. TT54893
…duct_matrix TT52360
…ndary uom without product in sale order line TT51683
In some cases we might want to skip the default secondary unit to be set. This change brings that possibility. TT52531
JochenDeBie
changed the title
|
/ocabot migration sale_order_secondary_unit |
alexey-pelykh
left a comment
alexey-pelykh
left a comment
There was a problem hiding this comment.
Migration looks clean — tests pass, pre-commit passes. The "Detect unreleased dependencies" check is failing though, which means product_secondary_unit hasn't been released for 19.0 yet. This PR will need that dependency merged first before it can land.
alexey-pelykh
left a comment
alexey-pelykh
left a comment
There was a problem hiding this comment.
Thanks for the migration, looks solid. Reviewed the full diff against 18.0 and the API adaptations are all on point: product_uom to product_uom_id rename in the mixin fields and compute, the onchange decoupled from onchange_product_id_warning into its own method, product_packaging_qty dropped from the depends, and the translation switched to parameterized env.(). Views and tests are updated accordingly.
One very minor nit: the comment in test_sale_order.py setUpClass still says "Remove this variable in v16" which has been stale for a while, but that is carried over from 18.0 and not something introduced here.
As noted in my earlier comment, this is blocked on the product_secondary_unit dependency (OCA/product-attribute#2222) being released for 19.0, but the migration itself is ready to go.
20 participants
Depends on:
This is only upgrading the code in the 18.0 branch as-is. Perhaps it's interesting to also look what happens on:
and: