[PM-34774] Add GET endpoint for organization invite links#7534
[PM-34774] Add GET endpoint for organization invite links#7534r-tome wants to merge 2 commits intoac/pm-34387/create-invite-link-commandfrom
Conversation
…vite links by organization ID - Implemented a new GET endpoint to fetch an invite link based on the organization ID. - Integrated IOrganizationInviteLinkRepository to handle data retrieval. - Updated tests to validate the new functionality, ensuring correct responses for existing and non-existing links. - Refactored service registration for invite link commands to improve clarity.
|
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## ac/pm-34387/create-invite-link-command #7534 +/- ##
==========================================================================
- Coverage 14.45% 14.45% -0.01%
==========================================================================
Files 1281 1281
Lines 55596 55607 +11
Branches 4303 4305 +2
==========================================================================
Hits 8037 8037
- Misses 47419 47430 +11
Partials 140 140 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…4/get-invite-link-query-and-endpoint
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE Adds Code Review Details
|
| [Authorize<ManageUsersRequirement>] | ||
| public async Task<IResult> Get(Guid orgId) | ||
| { | ||
| var link = await organizationInviteLinkRepository.GetByOrganizationIdAsync(orgId); |
There was a problem hiding this comment.
🎨 SUGGESTED: Controller calls repository directly instead of a query class; breaks the CQS pattern used elsewhere in this codebase.
Details and fix
The branch name (get-invite-link-query-and-endpoint) and the renamed DI extension (AddOrganizationInviteLinkCommandsQueries, plural) both imply a query class was intended, but only a command is still registered. The controller now injects IOrganizationInviteLinkRepository directly.
The sibling feature OrganizationDomains follows the expected pattern — see GetOrganizationDomainByOrganizationIdQuery registered alongside its commands. Per ADR-0008 (CQS), new features should use query classes for reads.
Suggested fix: introduce IGetOrganizationInviteLinkByOrganizationIdQuery / GetOrganizationInviteLinkByOrganizationIdQuery in src/Core/AdminConsole/OrganizationFeatures/InviteLinks/, register it in AddOrganizationInviteLinkCommandsQueries, and inject it into the controller instead of the repository. This also gives a natural home for the UseInviteLinks ability check raised in the other comment.
| [HttpGet("")] | ||
| [Authorize<ManageUsersRequirement>] | ||
| public async Task<IResult> Get(Guid orgId) | ||
| { | ||
| var link = await organizationInviteLinkRepository.GetByOrganizationIdAsync(orgId); | ||
|
|
||
| return link is null | ||
| ? TypedResults.NotFound() | ||
| : TypedResults.Ok(new OrganizationInviteLinkResponseModel(link)); | ||
| } |
There was a problem hiding this comment.
❓ QUESTION: Should Get also check the UseInviteLinks organization ability, consistent with CreateOrganizationInviteLinkCommand?
Details
CreateOrganizationInviteLinkCommand gates creation on OrganizationAbility.UseInviteLinks (commit 7acba07). If that ability is later disabled for an org that already has a link, this Get endpoint will still return the link, while Create would reject a new one. The controller-level RequireFeature(GenerateInviteLink) is a platform-wide flag, and ManageUsersRequirement is RBAC — neither is equivalent to the per-org ability check.
Is the intent for admins to continue to see/manage an existing link after the ability is turned off, or should Get also 404 when UseInviteLinks is false? A short comment or a consistency check here would clarify.
|





🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-34774
📔 Objective
Adds
GET /organizations/{orgId}/invite-linkto retrieve an organization's existing invite link. Returns 404 if none exists.