[Customer Portal][BE] Refactor types.bal into module and standardize update API response field names - #155
Conversation
Rashmika998
added
Type/Improvement
|
Warning Ignoring CodeRabbit configuration file changes. For security, only the configuration from the base branch is applied for open source repositories. 📝 WalkthroughWalkthroughConfiguration file extended to auto-review development branches. New types module introduced with comprehensive record definitions for product updates and vulnerabilities. Phone validation constant relocated to types module. Existing update types refactored to use hyphenated field names. Three utility functions added for update processing. Public signatures across service and utils standardized to use types namespace qualifier consistently. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts (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.
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/service.bal (1)
1204-1287:⚠️ Potential issue | 🟠 MajorBreaking change: update endpoints now return camelCase field names.
The update-related endpoints (
recommended-update-levels,updates/search,product-update-levels) now delegate toupdates:process*functions that map kebab-case wire-format fields to camelCase in the response. This changes the JSON field names seen by API consumers (e.g.,product-name→productName,starting-update-level→startingUpdateLevel).At least 9 frontend references expect kebab-case field names and will break with this change:
apps/customer-portal/webapp/src/models/responses.ts(lines 407, 414)apps/customer-portal/webapp/src/models/mockData.ts(lines 1729-1759)apps/customer-portal/webapp/src/api/__tests__/useGetProductUpdateLevels.test.tsx(lines 101, 126-129)Update frontend code to use camelCase field names (e.g.,
productName,productBaseVersion,startingUpdateLevel,totalUpdates,appliedUpdateNumbers).
🧹 Nitpick comments (1)
apps/customer-portal/backend/modules/updates/utils.bal (1)
51-122: Consider extracting repeatedBasicFileInfomapping into a helper.The
BasicFileInfokebab→camelCase mapping (5 fields) is repeated three times — once foraddedFiles(lines 65-71), once fororiginalFile(lines 77-81), and once fornewFile(lines 84-88). Extracting a small helper would reduce duplication and make future field additions less error-prone.♻️ Proposed helper extraction
+# Map a kebab-case BasicFileInfo to camelCase types:BasicFileInfo. +isolated function mapBasicFileInfo(BasicFileInfo info) returns types:BasicFileInfo => { + filePath: info.file\-path, + md5sum: info.md5sum, + sha256: info.sha256, + jwt: info.jwt, + downloadUrl: info.download\-url +};Then usage in
processListUpdatessimplifies to:types:BasicFileInfo[] addedFiles = from BasicFileInfo info in response.file\-changes.added\-files - select { - filePath: info.file\-path, - md5sum: info.md5sum, - sha256: info.sha256, - jwt: info.jwt, - downloadUrl: info.download\-url - }; + select mapBasicFileInfo(info); types:ModifiedFileInfo[] modifiedFiles = from ModifiedFileInfo info in response.file\-changes.modified\-files select { 'type: info.'type, - originalFile: { - filePath: info.original\-file.file\-path, - md5sum: info.original\-file.md5sum, - sha256: info.original\-file.sha256, - jwt: info.original\-file.jwt, - downloadUrl: info.original\-file.download\-url - }, - newFile: { - filePath: info.new\-file.file\-path, - md5sum: info.new\-file.md5sum, - sha256: info.new\-file.sha256, - jwt: info.new\-file.jwt, - downloadUrl: info.new\-file.download\-url - } + originalFile: mapBasicFileInfo(info.original\-file), + newFile: mapBasicFileInfo(info.new\-file) };
…al-types-refactor
shayanmalinda
left a comment
shayanmalinda
left a comment
There was a problem hiding this comment.
Let’s create a GitHub issue to remove these custom mappings once Ballerina supports JSON annotations for record types.
In the meantime, please also create an issue in Internal Ballerina Support:
https://github.com/wso2-enterprise/internal-support-ballerina
…al-types-refactor
c54b8b2
into
wso2-open-operations:customer-portal-milestone-1
github-project-automation
Bot
moved this from Todo
to Done
in Customer Portal Development
2 participants
Description
This PR refactors the existing
types.balfile into a dedicatedtypesmodule to enable reuse across modules. Additionally, it standardizes the response field names of update-related APIs by converting them from kebab-case to camelCase.Changes
types.balinto a newtypesmoduleReason
1. Modularization
Extracting
types.balinto a separate module improves:2. Naming Convention Alignment
Update-related API responses previously used kebab-case field names, which were inconsistent with the rest of the codebase. Initially, attempt was to preserve the external kebab-case contract by using Ballerina's
@jsondata:Name {"<name>"}annotation to map kebab-case JSON fields to internally defined camelCase fields. However, this approach did not work reliably in our scenario. Converting them to camelCase ensures:Impact
⚠ Field name changes in update API responses may be a breaking change for consumers relying on kebab-case.
Testing
Checklist
Summary by CodeRabbit
New Features
Refactor