Add Salesforce project and foundation ids to My CLAs rows - #5158
Conversation
GET /v4/my-clas already resolves the Salesforce ids of a CLA Group's projects_cla_groups mapping in order to fetch the project name and logo, then discards them. Consumers are left with no way to address the CLA Group in the LFX Corporate CLA Console. Keep those ids and emit them as optional projectSFID and foundationSFID. A foundation-level CLA Group - the marker mapping where project_sfid equals foundation_sfid - sends only foundationSFID; a single project-level mapping sends both; a multi-project group with no foundation marker sends neither, matching how projectName and projectLogo already behave. Presence is the discriminator, so consumers branch on which ids arrived rather than concatenating them. Consumer: linuxfoundation/lfx-self-serve#1575 Signed-off-by: ahmedomosany <aopeyemi@contractor.linuxfoundation.org>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Included review availability: 4 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. WalkthroughThe My CLA API now returns optional project and foundation Salesforce IDs. Resolution preserves mapping identifiers across supported cases, and documentation defines Corporate Console and Self Serve routing behavior. ChangesMy CLA Salesforce identifiers
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The change adds optional Salesforce identifiers while preserving existing responses and documents the supported mapping behavior; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant GetMyClas
participant MappingTable
participant ProjectService
GetMyClas->>MappingTable: read foundation and project SFIDs
GetMyClas->>ProjectService: resolve selected lookupSFID
ProjectService-->>GetMyClas: return project metadata or miss
GetMyClas-->>GetMyClas: populate projectSFID and foundationSFID
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (2 skipped: 2 unsupported.) ✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
Adds Salesforce project and foundation identifiers to /v4/my-clas rows for Corporate CLA Console deep links.
Changes:
- Extends the Swagger contract and API documentation.
- Populates IDs according to project-, foundation-, and unresolved-mapping rules.
- Adds unit coverage for mapping shapes and lookup degradation.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
docs/MY_CLAS_API.md |
Documents fields and consumer routing. |
cla-backend-go/v2/my_clas/service.go |
Resolves and returns Salesforce IDs. |
cla-backend-go/v2/my_clas/service_test.go |
Tests ID resolution behavior. |
cla-backend-go/swagger/common/my-cla.yaml |
Defines the optional response fields. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
lukaszgryglicki
left a comment
lukaszgryglicki
left a comment
There was a problem hiding this comment.
/lgtm - but please also create a mirrored PR based on main instead of dev - this would be for prod deployment.
What
GET /v4/my-clasnow returns two optional fields on each row:projectSFIDandfoundationSFID.Why
The endpoint already resolves the Salesforce ids of a CLA Group's
projects_cla_groupsmapping inorder to fetch
projectNameandprojectLogo, then throws them away. Consumers are left with no wayto address the CLA Group in the LFX Corporate CLA Console.
The immediate consumer is LFX Self Serve's My CLAs page, which is adding a "Manage in CCLA Console"
link for CLA managers — linuxfoundation/lfx-self-serve#1575.
Contract
Presence is the discriminator. Consumers branch on which ids arrived rather than concatenating them:
foundationSFIDprojectSFIDproject_sfid == foundation_sfid)/foundation/{foundationSFID}/cla/foundation/{foundationSFID}/project/{projectSFID}/claA foundation-level group deliberately omits
projectSFIDrather than echoing the foundation id intoboth, so a consumer can tell "foundation" apart from "project under a foundation" without comparing
ids. This matches
emails.CLAProjectParams.GetProjectFullURL, which ignoresProjectSFIDentirelyon its foundation branch. The unresolved case matches how
projectNameandprojectLogoalreadybehave.
Both fields marshal with
omitempty, so existing clients see no change.Changes
swagger/common/my-cla.yaml— declares both fields, with the branching rule in the description.v2/my_clas/service.go—projectInforetains the ids it already computed;GetMyClascopiesthem onto
models.MyCla. The local driving the project-service lookup is renamedprojectSFID→lookupSFID, since it can hold a foundation id; its log field key follows.docs/MY_CLAS_API.md— sample body, field reference, and the Self Serve mapping section.Testing
Swagger regenerated, then
make fmt,make build-mac,make test, andmake lintall passlocally (lint includes
./check-headers.shacross 3132 files).TestGetMyClasProjectNameAndLogocovers all three mapping shapes above.TestGetMyClasProjectLookupDegradesGracefullynow asserts both ids survive a project-serviceoutage, which proves they are mapping-derived rather than project-service-derived.