[Customer Portal][BE] Add APIs to Fetch Project Deployments and Deployed Products for Case Creation - #108
Conversation
Rashmika998
added
Type/Task
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughAdded entity client functions and DTOs plus mapping utilities, and exposed two HTTP GET endpoints to fetch project deployments and deployed products; endpoints validate input, extract user info, call entity functions, and return mapped responses or HTTP errors. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Service as Customer-Portal Service
participant Entity as Entity Module
participant API as Entity Backend API
Client->>Service: GET /projects/{id}/deployments
Service->>Service: extract user-info, validate id
Service->>Entity: getDeployments(idToken, projectId)
Entity->>API: POST /deployments/search (filters: {projectIds: [projectId]})
API-->>Entity: DeploymentsResponse
Entity-->>Service: DeploymentsResponse
Service->>Service: mapDeployments(...)
Service-->>Client: 200 DeploymentsResponse
Client->>Service: GET /deployments/{id}/products
Service->>Service: extract user-info, validate id
Service->>Entity: getDeployedProducts(idToken, deploymentId)
Entity->>API: POST /deployed_products/search (payload: {deploymentId})
API-->>Entity: DeployedProductsResponse
Entity-->>Service: DeployedProductsResponse
Service->>Service: mapDeployedProducts(...)
Service-->>Client: 200 DeployedProductsResponse
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@apps/customer-portal/backend/service.bal`:
- Around line 309-349: The deployments endpoint resource function get
projects/[string id]/deployments currently returns
DeploymentsResponse|http:BadRequest|http:Forbidden|http:InternalServerError but
does not handle http:STATUS_UNAUTHORIZED from entity:getDeployments; update the
function signature to include http:Unauthorized and add a branch after the
forbidden check that uses getStatusCode(deploymentsResponse) ==
http:STATUS_UNAUTHORIZED to log the unauthorized case (similar to
logForbiddenProjectAccess pattern or other endpoints) and return an
<http:Unauthorized> response with an appropriate message constant (e.g.,
ERR_MSG_PROJECT_ACCESS_UNAUTHORIZED) so 401s are handled explicitly rather than
falling through to InternalServerError.
- Around line 356-397: The endpoint currently calls
entity:getDeployedProducts(deploymentId) without scoping to projectId — fix by
first calling a deployment lookup (e.g., entity:getDeployment(deploymentId) or
an equivalent service) and verify the returned deployment.projectId matches the
route projectId; if it doesn't, call logForbiddenProjectAccess(projectId,
userInfo.userId) and return <http:Forbidden> with
ERR_MSG_PROJECT_ACCESS_FORBIDDEN. Alternatively, update
entity:getDeployedProducts to accept projectId and enforce the scope there. Also
handle authorization errors from entity calls by checking getStatusCode(...) ==
http:STATUS_UNAUTHORIZED and returning <http:Unauthorized> where appropriate.
Ensure you reference entity:getDeployedProducts, entity:getDeployment (or the
service that validates ownership), logForbiddenProjectAccess,
mapDeployedProducts, and getStatusCode in your changes.
🧹 Nitpick comments (1)
apps/customer-portal/backend/utils.bal (1)
224-225: Unnecessary.toString()ondeployment.id— it's already astring.
entity:ReferenceTableItem.idis typed asstring, so.toString()is redundant. Compare with line 202 whereproject.id(same type) is used directly without.toString(). This should be consistent.Suggested fix
- deployment: deployment != () ? {id: deployment.id.toString(), label: deployment.name} : () + deployment: deployment != () ? {id: deployment.id, label: deployment.name} : ()
791f9c1 to
2495fa7
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@apps/customer-portal/backend/service.bal`:
- Around line 954-955: Rename the misspelled variable customeErr to customError
and update all usages accordingly (e.g., change log:printWarn(customeErr) to
log:printWarn(customError)) so the naming is consistent with other endpoints;
make sure the string interpolation stays the same and no other references to
customeErr remain.
- Around line 930-931: Update the resource function get deployments/[string
id]/products to include http:Unauthorized in its return union and add a branch
that checks for ctx.request.httpStatus == STATUS_UNAUTHORIZED (or equivalent
constant) that returns http:Unauthorized before the existing STATUS_FORBIDDEN
handling; modify the signature
(DeployedProductsResponse|http:BadRequest|http:Forbidden|http:InternalServerError
-> include http:Unauthorized) and add the corresponding STATUS_UNAUTHORIZED case
in the same authorization/error-check sequence used by the deployments endpoint
to keep behavior consistent.
🧹 Nitpick comments (2)
apps/customer-portal/backend/service.bal (2)
942-948: Use a named constant for the deployment ID validation message.Line 945 uses a hardcoded string
"Deployment ID cannot be empty!"while sibling endpoints use constants likeERR_MSG_PROJECT_ID_EMPTYandERR_MSG_CASE_ID_EMPTY. Define and use anERR_MSG_DEPLOYMENT_ID_EMPTYconstant for consistency.Suggested fix
if isEmptyId(id) { return <http:BadRequest>{ body: { - message: "Deployment ID cannot be empty!" + message: ERR_MSG_DEPLOYMENT_ID_EMPTY } }; }
956-961: Use a named constant for the forbidden-access message.Line 958's
"Access to the requested deployment is forbidden!"is an inline string. Other endpoints use constants likeERR_MSG_PROJECT_ACCESS_FORBIDDENandERR_MSG_CASE_ACCESS_FORBIDDEN. Consider introducingERR_MSG_DEPLOYMENT_ACCESS_FORBIDDENfor consistency and easier maintenance.
1c3fdff to
dff0331
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/customer-portal/backend/utils.bal`:
- Around line 211-226: In mapDeployedProducts (returning
DeployedProductsResponse) remove the redundant .toString() call on deployment.id
so the mapping uses deployment.id directly (ReferenceTableItem.id is already a
string); update the select block where deployment is constructed to use {id:
deployment.id, label: deployment.name} to match the productModel mapping and
other ReferenceTableItem usages.
🧹 Nitpick comments (1)
apps/customer-portal/backend/service.bal (1)
942-960: Inline error strings break consistency with sibling endpoints.Other endpoints use named constants for error messages (e.g.,
ERR_MSG_PROJECT_ID_EMPTY,ERR_MSG_CASE_ID_EMPTY,ERR_MSG_PROJECT_ACCESS_FORBIDDEN). This endpoint uses inline string literals at lines 945 and 957. Extract these into constants for consistency and maintainability.Suggested approach
Define constants (in the same location as the existing ones):
const string ERR_MSG_DEPLOYMENT_ID_EMPTY = "Deployment ID cannot be empty!"; const string ERR_MSG_DEPLOYMENT_ACCESS_FORBIDDEN = "Access to the requested deployment is forbidden!";Then reference them in this endpoint:
- message: "Deployment ID cannot be empty!" + message: ERR_MSG_DEPLOYMENT_ID_EMPTY- message: "Access to the requested deployment is forbidden!" + message: ERR_MSG_DEPLOYMENT_ACCESS_FORBIDDEN
f2ebfe8 to
a8efcb9
Compare
512968d to
8892128
Compare
…tone-1-case-creation
dec3c36
into
wso2-open-operations:customer-portal-milestone-1
github-project-automation
Bot
moved this from In Progress
to Done
in Customer Portal Development
2 participants
Description
This PR adds new backend endpoints to fetch project deployments and deployed products, which are required for the Case Creation flow in the Customer Portal.
These APIs allow users to select the relevant deployment and product when creating a case, ensuring accurate case association.
The implementation follows existing API standards for validation, security, and response handling.
Endpoints Added
GET /projects/{projectId}/deploymentsGET projects/{projectId}/deployments/{deploymentId}/productsChanges Introduced
Scope
Testing
Related Issues
Related PRs
Summary by CodeRabbit