[16.0][ADD] product_variant_specific_description

[LoisRForgeFlow]

This module allows having different product variant internal notes than
the one of their template.

@ForgeFlow

[pedrobaeza]

Shouldn't product_description_by_variant or product_variant_specific_description (following other existing module) would be more descriptive?

[LoisRForgeFlow]

@pedrobaeza existing modules? I saw a couple of ones doing this and the name were sale_order_line_variant_description and product_variant_name.

[pedrobaeza]

I mean https://github.com/OCA/product-variant/tree/11.0/product_variant_specific_tax, that is being migrated to 16 in #302

[LoisRForgeFlow]

@pedrobaeza hmmm I guess there is not a clear pattern used till now, I can rename this one. Which one do you prefer? product_<field_name>_by_variant or product_variant_specific_<field_name>?

[pedrobaeza]

This is like asking which son is your favorite, hehe. No strong best option. You decide.

[LoisRForgeFlow]

Let's go for "specific" one, it has one ocurrence and this will be the second, better than start with zero 😆

[JordiMForgeFlow]

@LoisRForgeFlow maybe we could add the field in the product_variant_easy_edit_view view

[LoisRForgeFlow]

@JordiMForgeFlow Thanks for the heads-up, it is done now!

[JordiMForgeFlow]

Code + functional review 👍🏼

[LoisRForgeFlow]

Some improvements done in order to have a better UX:

• Template and variant descriptions are aligned while there is only one variant.
• Template description is hidden in the view as soon as there is more than 1 variant.
• Once any of the variants changes, the template description is cleared.
• A new test case is added to ensure this behavior.

[JordiMForgeFlow]

LGTM @LoisRForgeFlow , should we also consider this new approach in the init_hook, removing the description from the template when there are multiple variants?

[LoisRForgeFlow]

LGTM @LoisRForgeFlow , should we also consider this new approach in the init_hook, removing the description from the template when there are multiple variants?

The template description is only cleared when you modify the description of any of its variants, while all the variants have the same description, the template will do too. So I think the init hook is aligned with this behavior, you start with all variants with the same description as their template.

[LoisRForgeFlow]

@pedrobaeza Do you have some advice/hint on how to better handle a translatable+computed+stored field? Translations are not being aligned in this case.

[LoisRForgeFlow]

After some back and forth, there is no easy way to make it work correctly with translations, therefore a more pracmatic solutions has been followed:

This information message redirecting to the variant and the description as readonly will only be shown as soon as there is more than one language active.

[JordiMForgeFlow]

Tested again 👍🏼

[pedrobaeza]

Now that translations are handled with JSON fields, isn't there a way to "dump" the full content of the field? If not, this one is as you say a pragmatic one.

[JordiBForgeFlow]

Functional tests. Works as expected.

[JordiBForgeFlow]

/ocabot merge nobump

[OCA-git-bot]

On my way to merge this fine PR!
Prepared branch 16.0-ocabot-merge-pr-306-by-JordiBForgeFlow-bump-nobump, awaiting test results.

[LoisRForgeFlow]

Now that translations are handled with JSON fields, isn't there a way to "dump" the full content of the field? If not, this one is as you say a pragmatic one.

No, that would be ideal, but I guess is not supported yet. There are some helper methods to update translations (e.g. update_field_translations) but you need to call them explicitly and it gets a bit over-complicated to do it here. Let's hope they improve this in the ORM in the future.

[OCA-git-bot]

Congratulations, your PR was merged at 2ef8efe. Thanks a lot for contributing to OCA. ❤️