[PM-34429] Create an endpoint to retrieve the Invite

[JimmyVo16]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-38794

📔 Objective

1. Add an endpoint to retrieve the invite.
2. Use orgId to get the invite.
3. Validations:
   1. Invite link exists
   2. Request code matches database code
   3. Org has the UseInviteLinks ability
4. Exclude from validations
   1. Policies
   2. Existing org user
5. Add unit and integration tests.
6. Feature flag for Milestone 1.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 26 lines in your changes missing coverage. Please review.
✅ Project coverage is 14.97%. Comparing base (8ddca28) to head (d347a71).

Files with missing lines	Patch %	Lines
...es/InviteLinks/GetOrganizationInviteBlobCommand.cs	0.00%	21 Missing ⚠️
...es/InviteLinks/GetOrganizationInviteBlobRequest.cs	0.00%	4 Missing ⚠️
...eatures/OrganizationServiceCollectionExtensions.cs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@                             Coverage Diff                             @@
##           pm-40216/data-protect-invite-link-codes    #7994      +/-   ##
===========================================================================
- Coverage                                    14.98%   14.97%   -0.01%     
===========================================================================
  Files                                         1387     1389       +2     
  Lines                                        60261    60287      +26     
  Branches                                      4789     4793       +4     
===========================================================================
  Hits                                          9030     9030              
- Misses                                       51076    51102      +26     
  Partials                                       155      155              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This PR adds a POST /organizations/users/invite-link/invite endpoint that returns the opaque, client-decrypted invite for an invite link after validating link existence, a constant-time code match, organization enablement/UseInviteLinks, and email-domain allowance. The controller endpoint, command, request/response models, and DI registration all follow the established invite-link patterns (AcceptInviteLink/ConfirmInviteLink), and the change is well covered by unit tests across every branch plus an integration happy-path test.

Code Review Details

No blocking findings.

Notes considered and cleared during review:

• GetOrganizationInviteCommand reads org state from IOrganizationAbilityCacheService rather than IOrganizationRepository (unlike the sibling AcceptOrganizationInviteLinkCommand). This is acceptable for a read path where slight cache staleness is tolerable.
• The command intentionally omits the EmailVerified and existing-membership checks present in the accept flow; this matches the PR objective, since the endpoint only returns opaque encrypted invite data for client-side decryption.
• The secret code is a full GUID compared via CoreHelpers.FixedTimeEquals, so enumeration/brute-force is impractical.
• [Required] on non-nullable Guid fields in the request model is effectively a no-op, but this mirrors the existing AcceptOrganizationInviteLinkRequestModel convention.

Previously raised threads (dangling doc comment, integration test scope) were already resolved by the author and a human reviewer.

[JimmyVo16]

Hey @bitwarden/team-appsec , I know this PR is still in draft since it's branched off a feature branch instead of main, but could you take a look at it now? I'll need another review once the feature branch is merged.

[eliykat]

Re: the AppSec review - I'm not sure what the specific question is for them, but they don't review implementation code, so if you need their input make sure to message them via another channel.

Re: this PR - I thought we were going to check policies and all pre-join requirements before handing over the blob, since - in the context of milestone 3 - it contains the encrypted org key?

I tried to find this in the tech breakdown, but found only oblique references - it may have gotten dropped somewhere:

The main goal of enforcement before the confirm is to ensure the user qualifies as much as possible before giving them more data, aka the org key.

I don't think it's a blocker for the milestone 1 implementation (because the blob only contains the encrypted link key, which they already have, and a public fingerprint, which is public). But if we intend to reuse this for milestone 3 we'll need a follow up ticket to strengthen it.