[Customer Portal] Add multi select filter support for case search

[Rashmika998]

Description

• Add severity keys support for filtering cases.
• Add deployment IDs for filtering cases.

Summary by CodeRabbit

New Features

• Users can now filter cases by multiple case severities simultaneously
• Users can now filter cases by multiple deployments in a single search

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR extends the case search filtering capability by adding support for filtering by multiple case severities and deployments. The CaseSearchFilters type is updated across type definitions and the OpenAPI schema, with corresponding implementation changes to map these new array-based filter criteria through the search payload.

Changes

Multi-value case severity and deployment filters

Layer / File(s)	Summary
Filter type contracts and schema apps/customer-portal/backend/modules/entity/types.bal, apps/customer-portal/backend/modules/types/types.bal, apps/customer-portal/backend/openapi.yaml	CaseSearchFilters record extended with severityIds (array of case severity keys) and deploymentIds (array of deployment IDs) fields across entity module, API types, and OpenAPI schema to enable multi-value filtering.
Filter payload mapping apps/customer-portal/backend/utils.bal	searchCases function updated to construct searchPayload.filters with severityKeys (from payload.filters?.severityIds) and deploymentIds (from payload.filters?.deploymentIds), forwarding new array-based filter criteria to entity search service.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• wso2-open-operations/cs-tools#117: Updates CaseSearchFilters and searchCases payload in utils.bal with similar multi-value filter extensions (issueTypeKeys).
• wso2-open-operations/cs-tools#271: Extends CaseSearchFilters record in modules/entity/types.bal with additional optional filter fields (createdByMe).
• wso2-open-operations/cs-tools#113: Modifies severity-related fields in CaseSearchFilters and adjusts searchCases payload mapping for severity filtering.

Suggested reviewers

• shayanmalinda
• cloby99

Poem

🐰 A rabbit hops through filters bright,
With severities and deployments in sight,
Arrays replace the single key,
Multi-value searching now runs free!
Hop, hop—search filters multiply with glee! 🌟

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is minimal and missing most required template sections (Purpose, Goals, Approach, User stories, Release notes, Documentation, etc.), though it briefly identifies the core changes.	Expand the description to follow the repository template, including Purpose (with issue links), Goals, Approach, Release notes, and Documentation sections at minimum.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly and concisely describes the main change: adding multi-select filter support for case search in the Customer Portal, which is directly reflected in the changeset.
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]

Actionable comments posted: 1

🧹 Nitpick comments (1)

apps/customer-portal/backend/modules/entity/types.bal (1)

437-450: ⚖️ Poor tradeoff

Verify coexistence of singular and plural filter fields.

Both severityKey/severityKeys and deploymentId/deploymentIds pairs coexist in the filter record. If this is for backward compatibility during migration, consider:

• Documenting which fields are preferred
• Adding deprecation notices to the singular versions if they're being phased out
• Ensuring the implementation correctly handles precedence when both are provided

Note the type inconsistency: deploymentId is string (line 448) while deploymentIds uses the stricter IdString[] constraint (line 450).

🤖 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/backend/modules/entity/types.bal` around lines 437 -
450, The filter record defines both singular and plural fields (severityKey vs
severityKeys, deploymentId vs deploymentIds) and has a type mismatch
(deploymentId is string while deploymentIds is IdString[]); update the types and
handling so they are consistent and unambiguous: change deploymentId to
IdString? to match deploymentIds, mark singular fields (severityKey,
deploymentId) as deprecated in comments/Docs if you intend to migrate to plural
forms, and implement/verify precedence logic in the code that reads these
filters so when both singular and plural are provided (e.g., severityKey +
severityKeys or deploymentId + deploymentIds) you deterministically prefer one
(document which) and convert singular to a single-element plural internally;
ensure functions that consume these fields (search/filter handlers) accept the
normalized plural arrays.

🤖 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.

Inline comments:
In `@apps/customer-portal/backend/modules/types/types.bal`:
- Around line 63-64: Rename the field `severityIds` to `severityKeys` in the
types definition so it matches the entity module; update any direct references
within this module to use `severityKeys` (search for `severityIds` usages and
replace with `severityKeys`) and ensure the field type and comment remain the
same (int[]? and "List of case severity keys") to preserve behavior and
compatibility with the entity layer.

---

Nitpick comments:
In `@apps/customer-portal/backend/modules/entity/types.bal`:
- Around line 437-450: The filter record defines both singular and plural fields
(severityKey vs severityKeys, deploymentId vs deploymentIds) and has a type
mismatch (deploymentId is string while deploymentIds is IdString[]); update the
types and handling so they are consistent and unambiguous: change deploymentId
to IdString? to match deploymentIds, mark singular fields (severityKey,
deploymentId) as deprecated in comments/Docs if you intend to migrate to plural
forms, and implement/verify precedence logic in the code that reads these
filters so when both singular and plural are provided (e.g., severityKey +
severityKeys or deploymentId + deploymentIds) you deterministically prefer one
(document which) and convert singular to a single-element plural internally;
ensure functions that consume these fields (search/filter handlers) accept the
normalized plural arrays.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 693ac408-4f1b-443d-9bf3-c73c4243fe63

📥 Commits

Reviewing files that changed from the base of the PR and between 5da423b and 4df3391.

📒 Files selected for processing (4)

• apps/customer-portal/backend/modules/entity/types.bal
• apps/customer-portal/backend/modules/types/types.bal
• apps/customer-portal/backend/openapi.yaml
• apps/customer-portal/backend/utils.bal