-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[16.0][MIG] sale_order_secondary_unit: Migration to 16.0 #2645
Conversation
/ocabot migration sale_order_secondary_unit |
Test fails with secondary_uom_qty
price_unit
This could be due a change in how Odoo works with onchange and compute fields in Odoo 16 vs Odoo 15 What do you think @sergio-teruel ? |
Hi... you must do precompute this field in another PR Add precompute=True |
…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.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. 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/
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. 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/
Some inherited fields are set to `precompute=True` for performance. The test `test_secondary_uom_unit_price` was asserting a buggy behavior from v15 that is fixed automatically in v16 by the migration. Thus, we change the assertions. Now, when qtys change, the unit price is recomputed. That's the upstream behavior. It makes more sense, because you might have pricelists that depend on the qty. If you want to keep that old behavior, install `sale_order_qty_change_no_recompute`. @moduon MT-3490 Co-authored-by: Jairo Llopis <973709+yajo@users.noreply.github.com>
I don't know how it was possible for v15 code to work. Anyways, this compatibility is now tested and fixed. Upstream compute function is reused. @moduon MT-3490
c058e14
to
0fd8960
Compare
This module alters the behavior of sale order lines. Thus, it breaks others' tests. It must be isolated. @moduon MT-3490
I guess this migration is straight from previous versions, I've tested slowly and the migration is OK but this module introduce BUGs when working with Packaging at the same time @sergio-teruel @rousseldenis @Shide @yajo @anddago78 See my review: Odoo.16.-.sale_order_product_secondary_unit.-.rafaelbn.functional.test.mp4After seesing that this module should be improved to work 100% compatible with packging, I tested packaging un Odoo runbot separately https://www.loom.com/share/b3d62de28beb4385aadebabf8566baec?sid=847b0ec9-aec0-4eff-84ed-fc9a178ee86b Important:
This is a complicated module |
This module extends the functionality of sale orders to allow sale products in
secondary unit of distinct category.
MT-3490 @moduon @rafaelbn @fcvalgar @EmilioPascual please reviews :)
This PR superseed this one #2635
Pending:
See:
PR-16-sale_order_secondaty_unit.mp4
--