[19.0][MIG] website_sale_product_attribute_filter_category: Migration to version 19.0

[cristina-hidalgo-tecnativa]

• Reimplement the "Group by categories" toggle as an Owl Website Builder option (ProductsListPageOption extension) instead of the removed we-checkbox.
• Move the category-grouping xpath from products_attributes to product_attribute_filters_form, keeping the same $0-replace technique, with unique ids per category to avoid collisions between the sidebar and offcanvas renders.
• Update shop() override to match the new core signature and param names; use request.env._() per current translation convention.
• Update tour and tests accordingly.

@Tecnativa TT64160
@pedrobaeza @pilarvargas-tecnativa

[pedrobaeza]

/ocabot migration website_sale_product_attribute_filter_category

[pedrobaeza]

On a test in runboat, grouping by category duplicates children filters:

Other thing about migrating DBs: those with this option enabled in previous version, will it be kept in this one, or a migration script should handle it?

[pedrobaeza]

Incorrect indentation, and don't leave empty lines

[cristina-hidalgo-tecnativa]

On a test in runboat, grouping by category duplicates children filters:

Other thing about migrating DBs: those with this option enabled in previous version, will it be kept in this one, or a migration script should handle it?

Could you please review it again?

About the question, no migration script is needed. When updating an existing <template> record (not a fresh install), odoo/tools/convert.py (_tag_template) explicitly skips re-writing the active field if the view already exists.

So a DB that had "Group by categories" enabled in 18.0 keeps it enabled after upgrading — only inherit_id gets repointed to the new product_attribute_filters_form.

[pedrobaeza]

OK, now it works correctly on runboat, although 2 observations:

• The slider is not next to "Collapse sidebar sections", which is related.
• The new categories are collapsible by default, not respecting this other option.

And about migration, I'm still not sure, as if the previous view was active in 17/18, then when migrating, it's kept with noupdate=1, and not getting the new view spec. Let's see if @pilarvargas-tecnativa can confirm.

[pilarvargas-tecnativa]

This is one of the views that are duplicated when they are specifically enabled for a website. Those copies associated with the website are not updated when the module is updated; only the original view is updated. Therefore, I believe a migration script with website context would indeed be necessary.

[pedrobaeza]

I think this is a general problem for any activable view. We can try to mark all of those views to check if they are the same as the website_id=null ones, and if so, then update them after the migration with the new content of the agnostic view.