Revert "FWF-6254-task-listing-for-direct-assignees"

[arun-s-aot]

User description

Reverts #1143

---

PR Type

Other

---

Description

• Revert orQueries task filter handling

• Restore root group-based task criteria

• Stop payload criteria normalization

• Simplify FilterCriteria typing

---

Diagram Walkthrough

flowchart LR
  A["`orQueries`-based filters"]
  B["Root group-based criteria"]
  C["Task filter modal"]
  D["All tasks payload"]
  E["Request payload builder"]
  F["Filter type definitions"]
  C -- "restored to" --> B
  D -- "restored to" --> B
  E -- "passes through" --> B
  F -- "removes support for" --> A

Loading

File Walkthrough

	Relevant files
Bug fix	TaskFilterModalBody.tsx Revert modal filters to root criteria                                        forms-flow-review/src/components/TaskFilterModal/TaskFilterModalBody.tsx Restore top-level includeAssignedTasks Restore top-level candidateGroupsExpression Set candidateGroup for specific-role access Clear stale assignee or candidateGroup +18/-26  allTasksPayload.ts Restore all-tasks default group criteria                                  forms-flow-review/src/constants/allTasksPayload.ts Use root includeAssignedTasks criteria Use root candidateGroupsExpression criteria Keep existing created-date sorting +2/-9      taskHelper.ts Pass through existing task request criteria                            forms-flow-review/src/helper/taskHelper.ts Reuse clonedFilter?.criteria directly Keep merged process variable criteria Keep merged assignee and date filters Preserve sorting override construction +1/-20
Miscellaneous	taskFilter.ts Simplify task filter criteria typings                                        forms-flow-review/src/types/taskFilter.ts Make candidateGroupsExpression a direct field Narrow FilterCriteria to simpler shape +1/-3

---

[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

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ❌ 1143 - Not compliant Non-compliant requirements: Show tasks that are assigned directly to the current user in task lists. Replace group-only task filters with orQueries so both group-based tasks and direct assignee tasks are returned. Migrate or normalize legacy task filter payloads to the new query format. Extend task filter typings to support the new criteria shape needed for the above behavior.

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Regression Risk The rebuilt base criteria only query by candidateGroupsExpression and no longer include a direct-current-user assignee branch. This should be validated carefully because it appears to reintroduce the original bug where directly assigned tasks do not show up in filtered task lists. includeAssignedTasks: true, candidateGroupsExpression: "${currentUserGroups()}", Default List The default All Tasks payload now uses only group-based criteria. Please verify that tasks assigned directly to the current user still appear in the main task list, since this change seems to drop that matching path entirely. includeAssignedTasks: true, candidateGroupsExpression: "${currentUserGroups()}", Compatibility Making candidateGroupsExpression mandatory narrows the filter shape and may be incompatible with assignee-only filters or previously saved payloads that do not include this field. Existing consumers and persisted filters should be checked for breakage. candidateGroupsExpression: string;

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Restore direct-assignee matching Using only candidateGroupsExpression here drops tasks that are directly assigned to the current user but are not claimable by one of their groups. Restore the explicit assignee branch so the "All Tasks" view still returns both group-visible and directly assigned work items. forms-flow-review/src/constants/allTasksPayload.ts [11-18] criteria: { - includeAssignedTasks: true, - candidateGroupsExpression: "${currentUserGroups()}", + orQueries: [ + { + candidateGroupsExpression: "${currentUserGroups()}", + includeAssignedTasks: true, + }, + { + assigneeExpression: "${currentUser()}", + }, + ], sorting: [ { sortBy: "created", sortOrder: "asc", }, ], } Suggestion importance[1-10]: 9 __ Why: Using only candidateGroupsExpression with includeAssignedTasks can still exclude tasks that are directly assigned to the current user but not tied to one of their candidate groups. Restoring the explicit assignee OR branch materially affects correctness of the All Tasks results.	High
	Clear conflicting access filters The new access-option branches leave the default candidateGroupsExpression active, so a "specific role" or "specific assignee" search can still match the current user's groups and return the wrong task set. Clear the default group-based criteria whenever an explicit access scope is selected. forms-flow-review/src/components/TaskFilterModal/TaskFilterModalBody.tsx [187-202] if (accessOption === SPECIFIC_ROLE) { - const trimmedAccessValue = trimFirstSlash(accessValue); - criteria.candidateGroup = addTenantPrefixIfNeeded( - trimmedAccessValue, - tenantKey, - MULTITENANCY_ENABLED - ); + const trimmedAccessValue = trimFirstSlash(accessValue); + criteria.candidateGroup = addTenantPrefixIfNeeded( + trimmedAccessValue, + tenantKey, + MULTITENANCY_ENABLED + ); + delete criteria.candidateGroupsExpression; delete criteria.assignee; - } else if(accessOption === SPECIFIC_ASSIGNEE){ - criteria.assignee = accessValue; - delete criteria.candidateGroup; - } - else{ - delete criteria.assignee; - delete criteria.candidateGroup; - } +} else if (accessOption === SPECIFIC_ASSIGNEE) { + criteria.assignee = accessValue; + delete criteria.candidateGroup; + delete criteria.candidateGroupsExpression; + delete criteria.includeAssignedTasks; +} else { + delete criteria.assignee; + delete criteria.candidateGroup; +} Suggestion importance[1-10]: 8 __ Why: criteria is initialized with a default candidateGroupsExpression, so adding candidateGroup or assignee without clearing it can leave conflicting filters active and return the wrong task set. Removing the default group-based fields in the explicit access branches is a strong correctness fix for task filtering.	Medium
	Normalize legacy filter criteria Removing the criteria normalization reintroduces a regression for any persisted or default filter that still only has candidateGroupsExpression: directly assigned tasks disappear from the request. Normalize those criteria before building updatedFilter so both group and assignee matches are preserved. forms-flow-review/src/helper/taskHelper.ts [85-92] +const criteria = clonedFilter?.criteria || {}; + +if (!criteria.orQueries && criteria.candidateGroupsExpression) { + criteria.orQueries = [ + { + candidateGroupsExpression: criteria.candidateGroupsExpression, + includeAssignedTasks: true, + }, + { + assigneeExpression: "${currentUser()}", + }, + ]; + delete criteria.candidateGroupsExpression; + delete criteria.includeAssignedTasks; +} + const updatedFilter = { ...clonedFilter, criteria: { - ...clonedFilter?.criteria, + ...criteria, ...(processVariables.processVariables?.length && processVariables), ...(assignee.assignee && assignee), ...date, sorting: [newFilter], }, }; Suggestion importance[1-10]: 6 __ Why: If persisted filters still carry only candidateGroupsExpression, removing this normalization can change their behavior and hide directly assigned tasks when updatedFilter is rebuilt. The concern is plausible and useful, but the proposed fix reintroduces orQueries-based logic that the PR is otherwise moving away from, so its fit is only moderate.	Low