[Customer Portal][BE] Enhance feature configs and change request search response

[Rashmika998]

Summary

This PR enhances feature configurations and updates the change request search response to include product category–related fields.

Changes

1️⃣ Feature Config Enhancement

• Added new configuration fields:
  • defaultCaseProductCategories
  • srProductCategories
• Updated config models and mappings
• Ensured proper exposure via API/config endpoint

Reason:
These fields enable:

• Defining default product categories for cases
• Controlling service request (SR) related product categories
• Supporting dynamic feature behavior in frontend

---

2️⃣ Change Request Search Response Update

• Extended response model to include:
  • defaultCaseProductCategories
  • srProductCategories (if applicable in response)
• Updated DTOs/records and mapping logic
• Ensured consistent serialization

Reason:
Including product category data in responses:

• Reduces additional API calls
• Improves frontend filtering and display logic
• Aligns with updated feature configuration

Impact

• Response structure extended (non-breaking addition)
• Feature config enhanced (non-breaking)
• Improves flexibility and configurability

Testing

• Verified config endpoint returns new fields
• Tested change request search response includes updated fields
• Confirmed correct mapping and serialization

Summary by CodeRabbit

Release Notes

• New Features

  • Added configurable product category filters for deployed product search behavior in default case and service request creation workflows.
  • Enabled optional description field support for change requests.

• API Updates

  • Updated API schemas to reflect new product category filter options and change request description support.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR extends ProjectFeatures with optional product category filters (defaultCaseProductCategories, srProductCategories) for deployed product search, adds a description field to ChangeRequest, and removes the redundant description from ChangeRequestResponse since it inherits via composition. Service and utility layers are updated to use the renamed mapping function.

Changes

Cohort / File(s)	Summary
Type Definitions apps/customer-portal/backend/modules/entity/types.bal, apps/customer-portal/backend/modules/types/types.bal	Added defaultCaseProductCategories and srProductCategories optional array fields to ProjectFeatures. Added description field to ChangeRequest and removed it from ChangeRequestResponse to leverage composition via *ChangeRequest.
API Schema apps/customer-portal/backend/openapi.yaml	Updated ProjectFeatures schema with new nullable product category arrays and marked as required. Extended ChangeRequest schema with nullable description field. Removed description from ChangeRequestResponse schema. Added empty-string defaults to Account schema fields.
Service & Utilities apps/customer-portal/backend/service.bal, apps/customer-portal/backend/utils.bal	Renamed getProjectFeatures() to mapProjectFeatures() and updated service handler to call renamed function. Enhanced mapping logic to populate new product category fields from projectMetadata.features and propagate changeRequest.description into mapped objects.

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly Related PRs

• [Customer Portal][BE] Enhance deployed products search with productCategories filter #542: Introduces ProductCategory enum and deployed product search category filtering, foundational to the new defaultCaseProductCategories and srProductCategories fields.
• [Customer Portal[BE] Enhance change request response and include description in deployed product create/update payloads #279: Modifies ChangeRequest and ChangeRequestResponse entity types, addressing similar structural concerns with the description field handling.
• [Customer Portal][Backend] Add change request details endpoint and support soft delete in deployed product update #276: Updates ChangeRequest/ChangeRequestResponse types and their mapping functions, directly overlapping with the description field propagation logic.

Suggested Reviewers

• cloby99
• sacheeramesh
• shayanmalinda

Poem

🐰 Hoppy whiskers twitch with glee,
Categories bloom—one, two, three!
Descriptions flow where change requests rest,
Composition wins out, mapped out the best!
Updates aligned from schema to code,
This feature hops down the feature road! 🌟

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description covers purpose, goals, and approach, but lacks many required template sections including Purpose/Goals structure, Release notes, Documentation, Training, Certification, Marketing, detailed testing coverage, Security checks, and other critical sections.	Complete the full PR template by adding missing sections: Release note, Documentation, Training, Certification, Marketing, detailed Automation tests with coverage metrics, Security checks checklist, and Test environment details.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main changes: enhancing feature configs and updating change request search response for the Customer Portal backend.
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/backend/openapi.yaml (1)

4866-4932: ⚠️ Potential issue | 🟠 Major

Schema/type mismatch: defaultCaseProductCategories & srProductCategories are required in OpenAPI but optional in Ballerina.

In apps/customer-portal/backend/modules/types/types.bal (lines 296–298), these fields are declared as entity:ProductCategory[]? (optional-presence — they are omitted from JSON when unset). The OpenAPI schema, however, lists them under required (lines 4869, 4880). Since Ballerina's JSON serialization omits unset optional fields rather than emitting null, responses will violate the required contract whenever the upstream entity service returns nil for either field.

Either drop both from the required list (keeping nullable: true to allow null when explicitly set), or change the Ballerina fields to required-presence and guarantee they are always assigned.

📝 Proposed schema fix (option 1: drop from required)

     ProjectFeatures:
       required:
       - acceptedSeverityValues
-      - defaultCaseProductCategories
       - hasChangeRequestReadAccess
       - hasDeploymentReadAccess
       - hasDeploymentWriteAccess
       - hasEngagementsReadAccess
       - hasServiceRequestReadAccess
       - hasServiceRequestWriteAccess
       - hasSraReadAccess
       - hasSraWriteAccess
       - hasTimeLogsReadAccess
       - hasUpdatesReadAccess
-      - srProductCategories

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/customer-portal/backend/openapi.yaml` around lines 4866 - 4932, The
OpenAPI ProjectFeatures schema marks defaultCaseProductCategories and
srProductCategories as required but the Ballerina model declares them as
optional-presence (entity:ProductCategory[]?) in types.bal, causing mismatches;
either remove both defaultCaseProductCategories and srProductCategories from the
OpenAPI required array in the ProjectFeatures schema (keeping nullable: true if
you want to allow explicit null), or change the Ballerina fields to
required-presence (make them non-optional arrays) and ensure code always assigns
an array (possibly empty) before serializing; update whichever side you choose
so defaultCaseProductCategories and srProductCategories semantics match between
ProjectFeatures and types.bal.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@apps/customer-portal/backend/openapi.yaml`:
- Around line 4866-4932: The OpenAPI ProjectFeatures schema marks
defaultCaseProductCategories and srProductCategories as required but the
Ballerina model declares them as optional-presence (entity:ProductCategory[]?)
in types.bal, causing mismatches; either remove both
defaultCaseProductCategories and srProductCategories from the OpenAPI required
array in the ProjectFeatures schema (keeping nullable: true if you want to allow
explicit null), or change the Ballerina fields to required-presence (make them
non-optional arrays) and ensure code always assigns an array (possibly empty)
before serializing; update whichever side you choose so
defaultCaseProductCategories and srProductCategories semantics match between
ProjectFeatures and types.bal.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a6d920b9-6d81-45f0-bbc9-f0ca2c348243

📥 Commits

Reviewing files that changed from the base of the PR and between ed1e9d4 and f965412.

📒 Files selected for processing (5)

• 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/service.bal
• apps/customer-portal/backend/utils.bal