Project board header toolbar revamp - EXO-88315

[Jihed525]

What

Backport of #616 (squash-merged into feature/ai-contribution) onto develop.

Reworks the project board header toolbar to be compact and responsive (modelled on the Agenda/Documents toolbars), and makes task search usable on mobile:

• Board/List/Plan view selector becomes a compact icon + dropdown (TasksViewSwitcher, new component).
• Keyword search collapses behind a filter icon and expands full width (works on phones now).
• Advanced filter keeps its own icon with an applied-filter count.
• Removes the now-dead 30/70 toolbar CSS split and old tab styling.

Backport notes

Cherry-picked cleanly on top of the current develop (which since diverged and now includes #623 "Tasks UI revamp — project cards & list toolbars"). #623 touched tasks.less/ProjectCard*/ProjectListToolbar/TasksListToolbar but never touched TasksViewToolbar.vue or tasksViewSwitcher/projectBoardToolbar CSS selectors, so there's no functional overlap between the two — auto-merge only needed to interleave unrelated hunks in shared files (tasks.less, taskManagement_en.properties, initComponents.js).

Verified after cherry-pick:

• TasksViewSwitcher.vue/TasksViewToolbar.vue class names (tasksViewSwitcher, tasksViewSwitcherMenu, projectBoardToolbar, boardHeaderExtensions) all still resolve against the current tasks.less (post-feat: Tasks UI revamp — project cards & list toolbars - EXO-88314 #623 restructuring).
• Component registered once in initComponents.js, no duplicate/missing entries.

Test

• npx webpack --config webpack.prod.js --mode production → compiled with 0 errors (pre-existing lint warnings only, unrelated to this change).

🤖 Generated with Claude Code

[boubaker]

Reviewed the diff, the current state of the touched files on backport/EXO-88315-board-toolbar, cross-checked against TasksListToolbar.vue (already merged via #623) and the cited AgendaSwitchView.vue precedent in exoplatform/agenda, and checked SonarCloud's new issues for this PR.

Overview

Backport of #616: reworks the project board header into a compact, responsive toolbar (breadcrumb left, favorite/AI + view switcher + search + advanced filter grouped right), replacing the old v-tabs-based view selector with a new TasksViewSwitcher dropdown and making keyword search collapsible/full-width on mobile. All CI checks pass, including SonarCloud this time.

Main finding — TasksViewSwitcher reinvents what <v-menu> already does

The PR says it's "styled after agenda's AgendaSwitchView" — I pulled that component (exoplatform/agenda's agenda-webapps/.../top-toolbar/AgendaSwitchView.vue) to compare. It's a plain <v-menu offset-y close-on-click> with an #activator slot — no manual DOM manipulation.

TasksViewSwitcher.vue instead hand-rolls the same behavior: it moves the dropdown card to .v-application via appendChild, computes top/left from getBoundingClientRect() on open, and manages its own click/scroll listeners to close it. This is exactly what <v-menu> already does out of the box (it renders its content detached from the DOM flow specifically to escape ancestor stacking contexts) — the stated reason ("not trapped in a v-toolbar stacking context" / kanban board's 3D-transform compositing layers) is the textbook case <v-menu> is built to handle, and its own cited precedent doesn't need to work around it.

Side effects of the manual approach, all of which come for free with <v-menu>:

• No Escape-to-close on the switcher (the search field gets @keydown.esc, the switcher doesn't).
• Most of .tasksViewSwitcherMenu's CSS is dead on arrival: position: absolute, top, inset-inline-end and z-index: 1000 are all immediately overridden by the inline styles set in mounted()/positionMenu() (which use fixed, computed top/left, and zIndex: 9999). Only transform: translateZ(0) and the duplicate min-width actually matter at runtime. .tasksViewSwitcher { position: relative; } is similarly pointless once the child is reparented to .v-application with position: fixed.

Would suggest trying a plain <v-menu offset-y> first (matching AgendaSwitchView) and only reaching for the manual DOM-relocation approach if there's a concrete, reproducible issue with it inside the kanban board — in which case that's worth a one-line comment explaining what broke, so the next reader doesn't wonder why this component diverges from its own stated model.

Confirmed by SonarCloud (3 new MAJOR issues)

• TasksViewSwitcher.vue: change event triggered but not declared in emits.
• TasksViewToolbar.vue: keyword-changed event triggered but not declared in emits.
• TasksViewSwitcher.vue:103: prefer childNode.remove() over parentNode.removeChild(childNode).

All three go away if the <v-menu> simplification above is adopted (removes the manual DOM node teardown entirely) plus a one-line emits fix on the toolbar.

Checked and NOT a regression

• .tasksToolbar (and its .taskDisplay/.taskTabBoard/.taskTabList/.taskTabGantt/.projectTasksViewTabs children) is removed from tasks.less — verified its only consumer was the v-tabs markup this PR itself replaces in TasksViewToolbar.vue, so no orphaned-class situation like the one from #623's original cleanup.
• Dropping the resetFields('query') call from the keyword-change handler (so typing a search term no longer wipes the other active advanced filters) matches the behavior already shipped in the sibling TasksListToolbar.vue via #623 — consistent, not an accidental side effect of this rewrite.

Minor

• <v-text-field v-model="keyword" ... @input="onKeyword">: v-model already assigns this.keyword on input; onKeyword reassigns the same value again before debouncing. Harmless, just redundant.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Jihed525]

Thanks for the detailed review @boubaker — addressed all points in eea931c:

Main finding — TasksViewSwitcher reinvents <v-menu>
Replaced the manual DOM-relocation approach (appendChild to .v-application, getBoundingClientRect() positioning in positionMenu(), and the manual click/scroll listeners in mounted()/beforeDestroy()) with a plain <v-menu offset-y close-on-click>, structured exactly like AgendaSwitchView (activator slot wrapping the button, v-bind="attrs" v-on="on"). No more manual teardown, no more positionMenu/onScroll/onDocumentClick methods — v-menu already escapes the board's stacking context on its own, so the workaround wasn't needed.

Sonar's 3 new MAJOR issues

• TasksViewSwitcher.vue: added emits: ['change'].
• TasksViewToolbar.vue: added emits: ['keyword-changed'].
• TasksViewSwitcher.vue:103 (parentNode.removeChild): gone entirely — there's no manual node teardown left now that v-menu owns its own content lifecycle.

Dead CSS
Removed .tasksViewSwitcher { position: relative; } and the absolute-positioning block on .tasksViewSwitcherMenu (position, top, inset-inline-end, z-index, transform: translateZ(0)) from tasks.less — none of it applies once v-menu (not application code) controls where/how the content is rendered. Kept only min-width: 160px on .tasksViewSwitcherMenu, now as a standalone top-level rule (Vuetify applies content-class to .v-menu__content, which isn't nested under .projectBoardToolbar).

Minor — redundant this.keyword reassignment
Removed the manual this.keyword = term in onKeyword(); v-model="keyword" on the v-text-field already sets it before @input fires.

Verified after the change: eslint clean on both touched files, and npx webpack --config webpack.prod.js --mode production still compiles with 0 errors (same pre-existing warnings elsewhere, unrelated to this PR).

[boubaker]

Verified the fix commit (eea931c3) directly, not just the commit message:

• TasksViewSwitcher.vue now uses a plain <v-menu v-model offset-y close-on-click> with an #activator slot, matching AgendaSwitchView's pattern exactly — all the manual DOM-relocation/positioning/listener code is gone.
• emits: ['change'] / emits: ['keyword-changed'] added, clearing both Sonar-flagged undeclared-emit issues.
• Dead CSS trimmed: .tasksViewSwitcher { position: relative } removed, .tasksViewSwitcherMenu reduced to a standalone min-width: 160px rule (correctly moved out of .projectBoardToolbar nesting, since v-menu's content is teleported and wouldn't match the old nested selector anymore).
• onKeyword no longer redundantly reassigns this.keyword (v-model already does it) — confirmed the debounced $emit still reads the right value.

CI is green (PR Build, SonarCloud, Snyk) and SonarCloud's open-issue list for this PR is now empty.

Approving.