[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?

[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.

[pedrobaeza]

The collapse/uncollapse arrows are not working well for second and successive attributes in the same category:

[cristina-hidalgo-tecnativa]

The collapse/uncollapse arrows are not working well for second and successive attributes in the same category:

the $0 copy per category was leaving several attribute accordions with the same collapse id, so opening one toggled them all. Couldn't fix it safely via xpath (the desktop collapsible markup only exists when "Collapse sidebar sections" is on, so patching it there risked crashing the page). Fixed it in JS instead: a small Interaction gives each accordion item its own id after render.

[pilarvargas-tecnativa]

Could we handle the duplicated IDs directly in the QWeb template instead of adding a JavaScript interaction to modify them after rendering? I think it would be cleaner to fix the IDs and their references at the template level, while keeping $0 to reuse the original Odoo template. If JavaScript is strictly necessary, could you explain why this cannot be handled in XML?

Also, the current layout looks quite different from the standard Odoo 19 filters. The category headings, spacing and nested attribute filters should be adjusted to better match the native sidebar design.