[12.0][FIX] fix product.template related fields

[huguesdk]

make product.template.product_variant_id a stored computed field to avoid the following error when setting the print_category_id or to_print related fields:

non-stored field product.template.product_variant_id cannot be searched.

[legalsylvain]

Hello @huguesdk ! Je vais laisser la PR ouverte. la cible c'est désormais la V16, ou j'ai mis le module dans l'OCA.
ça joue ?
https://github.com/OCA/product-attribute/tree/16.0/product_print_category#product---print-categories

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (6e3c82c) 85.62% compared to head (a00f0c6) 85.62%.
Report is 7 commits behind head on 12.0.

Additional details and impacted files

@@           Coverage Diff           @@
##             12.0     #173   +/-   ##
=======================================
  Coverage   85.62%   85.62%           
=======================================
  Files         149      149           
  Lines        2330     2331    +1     
  Branches      360      360           
=======================================
+ Hits         1995     1996    +1     
  Misses        266      266           
  Partials       69       69           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[huguesdk]

ok, fine for me. i’ll test and create a similar pr for version 16 on the oca repo then.

[carmenbianca]

@huguesdk added a patch to your code, internal task T12969

[carmenbianca]

i also made a pr here : odoo/odoo#181811

[carmenbianca]

Upstream PR likely won't be merged. I added a new commit d5d7e05 61ae3f8 with a new insight to achieve the same result without overriding the compute method.

[huguesdk]

i don’t understand how this fixes the problem where an archived product template is duplicated and has no variants. _compute_product_variant_id() accesses product_variant_ids, which won’t contain archived variants. or am i missing something?

also, do you know why the test is failing?

[carmenbianca]

Fixed the test.

Between trying to upstream this and patching it here, I've also had a wrong assumption about how things work in Odoo 12.

In Odoo 12:

• When copying a product.template which has product variants, the copied result does NOT have any product variants.

In Odoo 15 (and maybe earlier):

• When copying a product.template which has product variants, the product.template.attribute.values (PTAVs) from which those product.products were generated are copied. Then, during the create method of the product.template, new product.products are created from those PTAVs.

---

To answer your question:

Indeed, when a product.template is inactive, _compute_product_variant_id() sets False, because product_variant_ids only contains archived products and will thus be an empty recordset. This appears to be by design, so we match upstream behaviour here.

When a template is (re)activated, instead of reactivating its product variants, new product.products are created from the PTAVs. Then by running our compute method after that has happened, product_variant_id is correctly populated.

But by running that compute method again when the template (and thus its also its variants) is unarchived, we get a sensible result. This matches upstream behaviour precisely.

[huguesdk]

nicely done, thanks for the explanation!

[carmenbianca]

@huguesdk i fixed this a final time with a solution that is way more obvious. the tests succeed on my machine.