fix: Favorites filter not applied on reload in the project view - EXO-88376#629
Merged
bmestrallet merged 1 commit intoJul 22, 2026
Conversation
…8376 Follow-up to #619/#624/#628 on @jihed_chabbeh's re-test: after a reload the "Favorites only" toggle and the filter count come back set, but the displayed list is not filtered. Root cause: the favorites filter is edited in one shared drawer but consumed by two dashboards, and #628 only fixed one of them. TasksFilterDrawer persists `favorite` into `filterStorage<projectId>+<tab>` for projects too, and restores the toggle (and TasksViewToolbar the count chip) from that same key — but TasksViewDashboard rebuilt `tasksFilter` with only groupBy/orderBy/ showCompletedTasks, dropping `favorite`, so the fetch on load went out unfiltered. Hence "the filter is set but the list is not". Fixes: - TasksViewDashboard: carry `favorite` through both restore paths (the `project` watcher and getTasksByProject) and the no-storage defaults. This also repairs the un-bookmark listener from #624, whose guard reads tasksFilter.favorite and silently bailed out after a reload. - TasksDashboard: sync filterTasks.favorite in the ALL branch of filterTaskQuery (a stale value re-applied the filter on any updateTasksList()), and drop the favorites restriction when the primary filter changes, so the list matches the drawer that resetFields() just cleared. - TasksListToolbar: restore the filter count from this view's own storage key, and stop the mount-time primary-filter re-emit which reset the drawer state and the count that had just been restored on every load. Verified live on a local 7.3 platform with a build of this branch: - project board: 6 tasks -> Favorites only -> 2 -> reload -> still 2, chip "1", initial request carries `favorite=true`; - My Tasks: 3 -> 1 -> reload -> still 1, chip now reads "Filter (1)" (was 0); - un-bookmark on a reloaded filtered board removes the row on the spot; - switching the primary filter clears the favorites restriction everywhere. Front-end only, lint clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Jihed525
added a commit
that referenced
this pull request
Jul 22, 2026
## What Backport of #619, #624, #628, #629 onto `develop`. Adds a **"Favorites only"** filter for tasks (follow-up to Favorites #615 / EXO-88316), with the fixes that followed after real-world testing: - **#619** — `favorite` query param on `GET /tasks/filter` (batched via `FavoriteService`) + a "Favorites only" toggle in the Sort & Filter drawer, persisted in localStorage. - **#624** — un-bookmarking a task now removes it from the favorites-filtered list immediately (list rows carry `favorite` state, front-end listens for `metadata.favorite.updated`); drawer star recolored to neutral grey. - **#628** — the persisted "Favorites only" toggle is now honored on the *first* fetch after a page reload in My Tasks (was previously applied only after the initial unfiltered fetch). - **#629** — same reload fix extended to the project/space board view, which #628 had missed. ## Backport notes Cherry-picked the 4 commits onto `develop`. Two conflicts, both resolved: - `TaskRestService.java`: import conflict (develop already had `FavoriteService` imported for an unrelated feature); also dropped a private `isFavorite(String, long)` helper introduced by #624 that duplicated `FavoriteUtil.isFavorite`, already present on `develop` since #622 (`Favorites for projects & tasks - EXO-88316`) — it was unused here since `getTaskById` on `develop` already goes through `FavoriteUtil`. - `TasksViewDashboard.vue`: #629's diff assumed `favorite` had been dropped from this file by an intermediate commit that only exists on `feature/ai-contribution`, not `develop` — on `develop` the field was already being carried through (from #619/#624), so the "fix" was already effectively in place; resolved by keeping upstream's exact wording where it was purely a stylistic difference (`!!x` vs `x || false`), for consistency. ## Test - `mvn -pl services -am -Dcheckstyle.skip=true -DskipTests install` → BUILD SUCCESS - `mvn -pl services -Dcheckstyle.skip=true -Dtest=TestTaskRestService test` → 20 tests, 0 failures/errors 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #619 / #624 / #628 on EXO-88376, addressing @jihed_chabbeh's re-test: "set to display favorite tasks on filter → refresh page: the filter is set but displayed list is not ok".
Root cause — #628 fixed only one of the two dashboards
The "Favorites only" filter is edited in one shared drawer but consumed by two dashboards:
favoriteTasksDashboard)TasksViewDashboard)TasksFilterDrawer.saveValueFilterInStorage()writesfavoriteintofilterStorage<projectId>+<tab>for projects too,open()restores the toggle from that key andTasksViewToolbarrestores the count chip fromfiltersNumber— butTasksViewDashboardrebuilttasksFilterwith onlygroupBy / orderBy / offset / limit / showCompletedTasks, droppingfavorite. So on load the request went out unfiltered while the UI showed the filter as set. (#628's statement that the project view "does not persist the favorite filter" was incorrect, which is how this slipped through.)Fixes
TasksViewDashboard.vue— carryfavoritethrough both restore paths (theprojectwatcher andgetTasksByProject) and the no-storage defaults. This also repairs the un-bookmark listener added in fix: un-bookmark removes the task from the Favorites filter + grey filter star - EXO-88376 #624, whose guard readstasksFilter.favoriteand therefore silently bailed out after a reload.TasksDashboard.vue— syncfilterTasks.favoritein theALLbranch offilterTaskQuery(a stale value re-applied the filter on anyupdateTasksList(): task added, assignee/priority/due-date changed), and clear the favorites restriction when the primary filter changes, so the list matches the drawer thatresetFields('primary')just cleared.TasksListToolbar.vue— restore the filter count from this view's own storage key (not the sharedfiltersNumber, also written by the project toolbar), and stop the mount-timeprimary-filter-taskre-emit that reset the drawer fields and the count restored moments earlier on every load.Front-end only, 3 files, +35/−3. eslint clean.
Verification
Built the services JAR + WAR from this branch and deployed on a local 7.3 platform:
1, and the initial request isGET /tasks/filter?projectId=1&…&favorite=true(wasfavorite=before).Known limitation (unchanged, out of scope)
TaskRestService.filterTasksfilters favorites after pagination (taskListis already the page), so in My Tasks (limit=20) a user whose favorites sit beyond the first page sees too few rows andtasksSize/ "Show more" are off. The project view is unaffected (limit=0). Happy to address it in a separate PR if you want it fixed now.🤖 Generated with Claude Code