[Customer Portal][Webapp] Enable multi-select for severity and deployment filters on dashboard cases table

[cloby99]

Purpose

• Enable multi-select for severity and deployment filters on dashboard cases table

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Enhanced cases table filtering to support selecting multiple severities and deployments simultaneously, allowing users to create more comprehensive filters when viewing and managing cases.

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request updates the cases table filtering mechanism to support plural array-based filter fields for severities and deployments. The type definition is updated to use severityIds and deploymentIds as string arrays, and the component logic now conditionally maps and passes these arrays when constructing the case search request.

Changes

Multi-select filter pluralization

Layer / File(s)	Summary
Filter type and component request construction apps/customer-portal/webapp/src/features/dashboard/types/casesTable.ts, apps/customer-portal/webapp/src/features/dashboard/components/cases-table/CasesTable.tsx	CasesTableFilterValues replaces singular severityId and deploymentId with plural severityIds and deploymentIds array fields. CasesTable updates its caseSearchRequest.filters construction to conditionally map severity ID strings to numbers and pass deployment ID strings as arrays when present.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• wso2-open-operations/cs-tools#750: Backend changes to accept and forward the same multi-select severityIds and deploymentIds array filter fields sent by this PR's frontend updates.
• wso2-open-operations/cs-tools#372: Previous frontend update to switch severity-related filter fields to an array-based form in the caseSearchRequest logic.
• wso2-open-operations/cs-tools#205: Parallel work updating the same caseSearchRequest.filters payload construction, adding support for additional filter types.

Suggested labels

Type/Improvement, Type/UX, App/Customer Portal, Area/Frontend, Platform/Web

Suggested reviewers

• Rashmika998
• SParaparan

Poem

🐰 Filters bloom from one to many,
Plural paths for all our queries,
Severities and deployments dance,
In arrays bright—no singular chance,
Multi-select magic, arrays advance!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is incomplete and only provides a brief Purpose statement; it is missing critical sections such as Goals, Approach, User stories, Release notes, Documentation, Testing, Security checks, and other required template sections.	Complete the PR description by filling in all required template sections, including Goals, Approach (with screenshots/GIFs for UI changes), test coverage details, security checklist, and documentation/training impacts.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: enabling multi-select for severity and deployment filters in the customer portal webapp dashboard cases table.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/customer-portal/webapp/src/features/dashboard/components/cases-table/CasesTable.tsx (1)

111-116: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Hide deployment filters consistently when includeDeploymentFilter is off.

Line 115 still clears the removed deploymentId key. If a deployment was already selected, Lines 207-210 will keep sending the hidden deploymentIds to the API, and Line 314 will still count that hidden filter as active.

Suggested fix

   const effectiveFilters: CasesTableFilterValues = useMemo(
     () =>
       includeDeploymentFilter
         ? filters
-        : { ...filters, deploymentId: undefined },
+        : { ...filters, deploymentIds: undefined },
     [filters, includeDeploymentFilter],
   );
@@
-  const activeFiltersCount = countCasesTableActiveFilters(filters);
+  const activeFiltersCount = countCasesTableActiveFilters(effectiveFilters);

Also applies to: 207-210, 314-314

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@apps/customer-portal/webapp/src/features/dashboard/components/cases-table/CasesTable.tsx`
around lines 111 - 116, The code still sends and counts a hidden deploymentId
because parts of the component use the original filters instead of the computed
effectiveFilters; update all places that build the API request payload and the
active-filter count to use effectiveFilters (or explicitly omit deploymentId
when includeDeploymentFilter is false) so deploymentId is removed from the
outgoing query and not counted as an active filter; specifically, ensure the API
request construction (where filters are sent) and the active-filters calculation
reference effectiveFilters (and/or perform a conditional delete of deploymentId
when includeDeploymentFilter === false) rather than the raw filters variable.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In
`@apps/customer-portal/webapp/src/features/dashboard/components/cases-table/CasesTable.tsx`:
- Around line 111-116: The code still sends and counts a hidden deploymentId
because parts of the component use the original filters instead of the computed
effectiveFilters; update all places that build the API request payload and the
active-filter count to use effectiveFilters (or explicitly omit deploymentId
when includeDeploymentFilter is false) so deploymentId is removed from the
outgoing query and not counted as an active filter; specifically, ensure the API
request construction (where filters are sent) and the active-filters calculation
reference effectiveFilters (and/or perform a conditional delete of deploymentId
when includeDeploymentFilter === false) rather than the raw filters variable.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 3bc5f1ee-6ff2-4107-9a06-f9559e134082

📥 Commits

Reviewing files that changed from the base of the PR and between 8ecf750 and 8a87d00.

📒 Files selected for processing (2)

• apps/customer-portal/webapp/src/features/dashboard/components/cases-table/CasesTable.tsx
• apps/customer-portal/webapp/src/features/dashboard/types/casesTable.ts