Repository navigation
[20.0][MIG] web_filter_header_button: Migration to 20.0 - #3779
CarlosRoca13 wants to merge 11 commits into
Conversation
Now we can configure group filters to show up along the other filters so users can easily access those as well. TT49232
When there are too many buttons, they won't fit in the window and they will overlap with other ui elemnets. We can prevent it putting them in their own row. TT49431
In custom views, like the reconciliation one, that use the control panel we must prevent loading the FilterButton component. TT49664
…rrors referring self
|
The following commit authors need to sign the Contributor License Agreement: |
OCA-git-bot
added
mod:web_filter_header_button
|
/ocabot migration web_filter_header_button |
Andrii9090-tecnativa
left a comment
Andrii9090-tecnativa
left a comment
There was a problem hiding this comment.
I tested this on Runboat, and it works with the sample filters and groupings. For example, grouping by status in Apps works correctly.
I added the following filter to the Sales Order search view to group orders by date, and it doesn't work
Other filters in the Sales Order search view work correctly with the same shown_in_panel context.
Could you please check whether date groupings are handled correctly?
chienandalu
left a comment
chienandalu
left a comment
There was a problem hiding this comment.
I'd fix this tiny gap between the buttons.
| onClickToggleHeaderButtonFilters() { | ||
| const visible = !this.headerButtonFiltersState.visible; | ||
| if (visible) { | ||
| browser.localStorage.setItem(this.buttonFiltersVisibilityKey, true); |
There was a problem hiding this comment.
The read at line 19 is guarded with if (actionId), but the write here is not. For control panels without an action (e.g. the "Search More…" SelectCreateDialog, where env.config.actionId is false), toggling the buttons stores visibleHeaderButtonsfalse+<uid> in localStorage.
That key is never read back, so the dialog always opens with the buttons hidden, and every actionless control panel shares the same stale entry. I reproduced it: open Contacts → a many2one → "Search More…" → toggle the funnel → the key appears in Local Storage.
My suggestion would be only to persist (and remove) the key when actionId is set, keeping the visibility state in memory otherwise.
| } | ||
| // Font Awesome isn't available anymore, so the old `fa-*` icons would | ||
| // be rendered as plain text. | ||
| if (options.icon?.startsWith("fa-")) { |
There was a problem hiding this comment.
startsWith("fa-") only catches the fa-star form. Legacy contexts using the full Font Awesome syntax ('icon': 'fa fa-star') slip through, and since .oi::before renders content: attr(data-icon), the button ends up showing a stray fa fa- text next to the glyph (the font turns star into the icon but the rest is plain text).
The migration script already handles both forms (ICON_RE accepts fa[\w\s-]*), so the runtime guard should be consistent with it for views/filters that haven't been migrated yet. Something like /(^|\s)fa-/.test(options.icon) would cover both.
e78f622 to
543bad8
Compare
543bad8 to
8798187
Compare
|
Changes done! |
cc @Tecnativa TT65487
ping @pilarvargas-tecnativa @cristina-hidalgo-tecnativa