[Customer Portal][BE] Fix updates/search payload field and remove unnecessary idToken passing

[Rashmika998]

Description

This PR corrects the payload field used in the updates/search API and removes unnecessary idToken propagation to the updates service.

Changes

Payload Field Correction

• Updated productBaseVersion → productVersion in the updates/search request payload
• Adjusted related DTOs and mappings
• Ensured alignment with the actual service contract

Remove idToken Passing

• Removed idToken forwarding to the updates service
• Cleaned up related request headers and service logic

Reason

Payload Fix

The updates/search API was previously using productBaseVersion, which does not match the actual expected field name (productVersion). This caused contract inconsistency and potential integration issues.

Token Removal

The updates service authenticates using the client credentials grant, and does not require a user token (idToken). Passing the idToken was unnecessary and misleading from an authentication standpoint.

Removing it:

• Simplifies the request
• Aligns with proper OAuth flow usage
• Avoids confusion between user-level and service-level authentication

Impact

• Payload field correction may affect consumers relying on the incorrect field name
• No functional impact expected after idToken removal

Related Issues

• [Customer Portal][BE] Fix updates/search payload field and remove unnecessary idToken propagation #171

Summary by CodeRabbit

• Refactor
  • Update endpoints no longer require token-based authentication for listing updates and fetching product update levels.
  • Product fields (name, version, channel) are now explicit in update payloads with non-empty validation.
  • Product version field renamed in update requests.
  • Removed generation of unused authentication headers.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Removed the exported BasicProductInfo type and inlined its fields into ListUpdatePayload; renamed product-base-version → product-version; removed token/header-based authentication and generateHeaders usage, updating related function signatures and call sites.

Changes

Cohort / File(s)	Summary
Type definitions apps/customer-portal/backend/modules/types/types.bal, apps/customer-portal/backend/modules/updates/types.bal	Removed public BasicProductInfo. ListUpdatePayload now inlines product fields (productName/productVersion/channel) with minLength constraints instead of embedding *BasicProductInfo.
Updates module logic apps/customer-portal/backend/modules/updates/updates.bal, apps/customer-portal/backend/modules/updates/utils.bal	Removed generateHeaders(token) and idToken/header propagation. Updated signatures: listUpdates and getProductUpdateLevels (and callers) no longer accept idToken. Request payload field renamed from product-base-version → product-version.
Service layer call sites apps/customer-portal/backend/service.bal	Call sites updated to match new signatures: processListUpdates(payload) and processProductUpdateLevels() — idToken no longer passed through.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• [Customer Portal][BE] Fix updates/search payload field and remove unnecessary idToken propagation #171 — Matches code-level changes: renames product-base-version → productVersion and removes idToken/header propagation.

Possibly related PRs

• [Customer Portal][BE] Standardize update API field names in requests and responses #124 — Edits to BasicProductInfo/ListUpdatePayload types overlap with these type changes.
• [Customer Portal][BE] Add updates endpoints #98 — Related changes in updates module functions and removal of token-based header usage.
• [Customer Portal][BE] Refactor types.bal into module and standardize update API response field names #155 — Touches the same update-related type definitions and field renames.

Suggested reviewers

• sacheeramesh
• kasunsiyambalapitiya

Poem

"I nibble types and hop through code,
Fields unpacked along the road.
Tokens hidden, calls made light,
Payloads tidy, schema bright.
— a rabbit, coding by moonlight 🐇"

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The PR description provides clear purpose, goals, reasoning, and impact, but does not follow the repository's required template structure with formal sections like Purpose, Goals, Approach, Release note, Documentation, Security checks, and Test environment.	Reformat the description to follow the repository's template structure, including sections for Purpose, Goals, Approach, Release note, Documentation, Security checks, Automation tests, and Test environment details.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the two main changes: fixing the payload field (productBaseVersion → productVersion) and removing unnecessary idToken passing in the updates service.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into customer-portal-milestone-1

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

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

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 (3)

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

143-161: ⚠️ Potential issue | 🟡 Minor

Stale doc comment: "Product base version" should be "Product version".

Line 147 still says # Product base version but the field was renamed to product\-version. Update the comment to match.

📝 Proposed fix

     # Product name
     `@constraint`:String {minLength: 1}
     string product\-name;
-    # Product base version
+    # Product version
     `@constraint`:String {minLength: 1}
     string product\-version;

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

26-32: ⚠️ Potential issue | 🟡 Minor

idToken parameter is accepted but unused.

listUpdates still accepts idToken (line 30), and processListUpdates in utils.bal still forwards it (line 57), but the actual endpoint call on line 31 never uses it. Since this PR's goal is to remove idToken passing to the updates service, consider removing it from listUpdates, processListUpdates, and the call site in service.bal as well.

📝 Suggested change for this function

 # List updates based on the provided parameters.
 #
-# + idToken - ID token for authentication
 # + payload - Payload for listing updates
 # + return - List of updates, or an error if the operation fails
-public isolated function listUpdates(string idToken, ListUpdatePayload payload) returns UpdateResponse|error {
+public isolated function listUpdates(ListUpdatePayload payload) returns UpdateResponse|error {
     return updatesClient->/updates/list\-updates.post(payload, readOnly = true);
 }

apps/customer-portal/backend/service.bal (1)

1198-1198: ⚠️ Potential issue | 🟡 Minor

idToken is still passed to processListUpdates here but is unused downstream.

As noted in updates.bal, the idToken flows through processListUpdates → listUpdates but is never sent to the updates service. If the intent is to fully remove token passing, clean up this call chain too.