-
Notifications
You must be signed in to change notification settings - Fork 10.2k
fix: Use Memberships with OWNER role for platform owner lookup #22475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix: Use Memberships with OWNER role for platform owner lookup #22475
Conversation
@sahitya-chandra is attempting to deploy a commit to the cal Team on Vercel. A member of the Team first needs to authorize it. |
Graphite Automations"Add consumer team as reviewer" took an action on this PR • (07/14/25)1 reviewer was added to this PR based on Keith Williams's automation. "Add community label" took an action on this PR • (07/14/25)1 label was added to this PR based on Keith Williams's automation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cubic reviewed 2 files and found no issues. Review PR in cubic.dev.
WalkthroughApiAuthStrategy now injects MembershipsRepository and calls membershipsRepository.findPlatformOwnerUserId(client.organizationId) in oAuthClientStrategy instead of profilesRepository.getPlatformOwnerUserId(...). A new MembershipsRepository.findPlatformOwnerUserId(organizationId) method was added; it queries memberships for teamId = organizationId, role = "OWNER", accepted = true and returns the owner userId or null. No other logic or error handling changes were made. Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Assessment against linked issues
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
✨ Finishing Touches
🧪 Generate 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.ts
(3 hunks)apps/api/v2/src/modules/memberships/memberships.repository.ts
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Install dependencies / Yarn install & cache
- GitHub Check: Security Check
🔇 Additional comments (3)
apps/api/v2/src/modules/memberships/memberships.repository.ts (1)
23-36
: LGTM! The method correctly implements platform owner lookup.The implementation properly queries the membership table with the correct filters (teamId, role, accepted) and handles the null case appropriately. This addresses the issue where the previous approach could incorrectly identify managed users as platform owners.
apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.ts (2)
7-7
: LGTM! Dependency injection implemented correctly.The MembershipsRepository is properly imported and injected following the established patterns in the codebase.
Also applies to: 62-62
188-188
: LGTM! Method call change correctly implements the fix.The change from
profilesRepository.getPlatformOwnerUserId
tomembershipsRepository.findPlatformOwnerUserId
properly addresses the issue where managed users could be incorrectly identified as platform owners. The new approach correctly validates actual ownership through membership roles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @sahitya-chandra thanks for the pr, can you please address the unit test failing. Also it will be good to add a loom.
@Devanshusharma2005 unit tests have been passed, and the changes are also not complex. |
@anikdhabal can you review this sir... |
@sahitya-chandra We will review it. Can you pls add a loom video? |
@kart1ka sir, I am unable to create a loom video of this fix because locally running the api needs x_cal_secret which I don't have... |
What does this PR do?
Replaced the logic for identifying the platform owner from the Profiles table (ordered by createdAt) with a direct lookup in the Memberships table using the 'OWNER' role. This prevents managed users from being mistakenly treated as platform owners if the original owner is deleted.
Visual Demo (For contributors especially)
A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).
Video Demo (if applicable):
Image Demo (if applicable):
Mandatory Tasks (DO NOT REMOVE)
How should this be tested?
Checklist
Summary by cubic
Changed platform owner lookup to use the Memberships table with the OWNER role instead of Profiles, ensuring only valid owners are identified.