[19.0][MIG] product_dimension: Migration to 19.0.#2089
[19.0][MIG] product_dimension: Migration to 19.0.#2089hieulucky111 wants to merge 61 commits intoOCA:19.0from
Conversation
osv -> orm test computation of volume in same UOM add test with conversion from cm refactor, new API, generic UOM computation fix wording in readme do not use camelcase for Models put dimensions in their own group Otherwise they are shown as weights. fill in placeholders in README README is actually rst, not md use a new-api onchange, update tests, refactor Also, spell "height" correctly.
…also with other languages than english
…ct_supplierinfo_tree_price_info
REF remove executable permission ADD missing tag images Conflicts: product_dimension/__openerp__.py
FIX remove oldname in field height ADD onchange calculate volume on product template
[MIG] Make modules uninstallable [MIG] Rename manifest files
… due to rounding issues (OCA#284)2
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: product-attribute-12.0/product-attribute-12.0-product_dimension Translate-URL: https://translation.odoo-community.org/projects/product-attribute-12-0/product-attribute-12-0-product_dimension/
Currently translated at 100.0% (8 of 8 strings) Translation: product-attribute-12.0/product-attribute-12.0-product_dimension Translate-URL: https://translation.odoo-community.org/projects/product-attribute-12-0/product-attribute-12-0-product_dimension/es/
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: product-attribute-12.0/product-attribute-12.0-product_dimension Translate-URL: https://translation.odoo-community.org/projects/product-attribute-12-0/product-attribute-12-0-product_dimension/
Currently translated at 100.0% (11 of 11 strings) Translation: product-attribute-12.0/product-attribute-12.0-product_dimension Translate-URL: https://translation.odoo-community.org/projects/product-attribute-12-0/product-attribute-12-0-product_dimension/pt/
Currently translated at 100.0% (11 of 11 strings) Translation: product-attribute-13.0/product-attribute-13.0-product_dimension Translate-URL: https://translation.odoo-community.org/projects/product-attribute-13-0/product-attribute-13-0-product_dimension/de/
Currently translated at 100.0% (11 of 11 strings) Translation: product-attribute-13.0/product-attribute-13.0-product_dimension Translate-URL: https://translation.odoo-community.org/projects/product-attribute-13-0/product-attribute-13-0-product_dimension/fr/
|
/ocabot migration product_dimension |
|
/ocabot migration product_dimension |
| "uom.uom", | ||
| "Dimensional UoM", | ||
| help="UoM for length, height, width", | ||
| default=lambda self: self.env.ref("uom.product_uom_meter"), |
There was a problem hiding this comment.
@hieulucky111 I think this default isn't working as intended since it's overriding the unit I choose when creating a product manually. I'm unsure if this is the case for previous versions though.
Also, this is more of a personal doubt. Since UoM categories no longer exist in v19 should we try and filter the available uoms for this field somehow? Odoo's approach in some settings fields is just to hardcode a couple of UoM for each category though I don't quite like it.
https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/addons/product/models/res_config_settings.py#L14
There was a problem hiding this comment.
Hello @ferran-S73
I’ve rechecked the behavior in both versions 18 and 19. When creating a new Product Template and selecting a Dimension UoM, the selected UoM disappears after saving. (Same issue in both versions)
Regarding the UoM filter, we could use a System Parameter to store the list of available UoM names. However, I don’t think that’s necessary for now.
There was a problem hiding this comment.
It's likely that this issue can be solved by aligning with how Odoo does this for weight, by storing the UoM on the product template (https://github.com/odoo/odoo/blob/27b3d2fc055c586f4d53c92f5a7a93301d7d7d17/addons/product/models/product_template.py#L110-L113).
There was a problem hiding this comment.
hello @StefanRijnhart, do you see this as a critical blocker, or can we treat it as a future enhancement?
Personally, I think we can address this in a later.
There was a problem hiding this comment.
I'd say it's pretty serious if this module provides a field that is not stored when creating a new record even if the user has selected a value for it. The product.template model is now more prominent than back when this (old) module was first introduced, so the impact of the bug has gotten bigger even if the bug has existed in past versions.
There was a problem hiding this comment.
Ok, i will improve this soon.
There was a problem hiding this comment.
hello @StefanRijnhart, i have applied your suggestion. I also move the default UoM from product.product to product.template. (Because variant creation will set again the value of product template).
Thank you.
There was a problem hiding this comment.
Thanks for the update! Checking runboat, I still seem to be able to reproduce the original issue. Did it work for you while testing locally?
There was a problem hiding this comment.
Yes, it works for me before pushing the updated code. Maybe we need to upgrade again module?
There was a problem hiding this comment.
Weird. The failure to store the dimensional uom when creating product templates is easily reproced in a test, it turns out. The solution is also easy: apparently, a similar issue occurs with the other fields in this module, and this is fixed with the override on _prepare_variant_values. Fix proposed onto your branch in komit-consulting#1. You can squash it into your own commit.
|
@OCA/product-maintainers Please, can you merge this PR? |
|
This PR has the |
|
LGTM |
|
@rousseldenis could you merge this one? :) |
|
Is there no interest in fixing #2089 (review)? |
|
@OCA/product-maintainers Hello, is there anything missing, before we can get the PR merged ? 🙂 |
8b8b9bb to
ce7c56b
Compare
ce7c56b to
2ff7c80
Compare
|
@rousseldenis could this one be merged? |
|
@JordiMForgeFlow Let's wait until #2089 (review) is fixed. We found the solution now. |
No description provided.