Repository navigation
[13.0][FIX] product: merge product variants with same attributes - #2513
MiquelRForgeFlow wants to merge 1 commit into
Conversation
|
I can retarget to v11 branch if you prefer. |
|
We have not the constrain for combination_indices in pre-migration so maybe better to calculate combination_indices and then group product by product template and combination_indices? |
cfd69a8 to
e297acb
Compare
e297acb to
29d8bb4
Compare
29d8bb4 to
a1f3395
Compare
|
Hi, @MiquelRForgeFlow Could you rebase it? |
a1f3395 to
c272fd6
Compare
|
Maybe need to be added in a commit? odoo/odoo#32086 |
pedrobaeza
left a comment
pedrobaeza
left a comment
There was a problem hiding this comment.
Shouldn't you update combination_indices after the merge?
No, why? The combination_indices are the same, they don't change. |
| for template_id in templates: | ||
| openupgrade_merge_records.merge_records( | ||
| env, 'product.product', templates[template_id][1:], | ||
| templates[template_id][0], field_spec=None, method='sql', |
There was a problem hiding this comment.
The question now is: should I put a field_spec?
There was a problem hiding this comment.
It depends if the standard fields require it or default merge values are enough
There was a problem hiding this comment.
Yeah, my best option is {'default_code': 'first_not_null', 'active': 'or', 'barcode': 'first_not_null', 'volume': 'max', 'weight': 'max'}. My concern is for custom modules that add float/char/boolean fields, which would need to add more things in this dict. Maybe we could add in openupgradelib a functionality like if the dict contains 'other_fields': 'preserve', then every other field is excluded and preserved.
There was a problem hiding this comment.
|
My take on this is that merging complete products is something that shouldn't be corrected at OpenUpgrade level. If they have done such ugly thing, then it must be fixed before doing the migration. |
|
Ok (don't delete branch) |
|
FYI this PR fixed our issue where we have a product with same attributes |
|
I’d like to draw your attention to this one #6070 |
Before odoo/odoo@088edee2ce71 ("[FIX] product: do not create duplicate variants", odoo/odoo#35013), Odoo 12 reactivated archived variants whose combination already had an active variant (sell the variants, remove an attribute from the template, add it again). That fix prevents new duplicates but doesn't clean the existing ones, so v12 databases can contain several active variants for the same combination, and the creation of the product_product_combination_unique index on v13 fails. Variants without attribute values get an empty combination_indices, as Odoo computes it, so they are also covered. For each template and combination, the variant with the lowest ID is kept active and the others are archived: unlike #2513, no records are merged or deleted. Assisted-by: Claude Opus 5.5
Make use of merge_records tool to merge records.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr