[PM-40248] feat: Enforce Send access controls via Send Controls policy

[matt-livefront]

🎟️ Tracking

PM-40248

📔 Objective

Enforce the Send Controls policy's access control option (whoCanAccess) on iOS, behind the pm-31885-send-controls feature flag. When an organization requires a specific access option, the Send add/edit "Who can view" menu shows the enforced value and is disabled, and the required option is forced:

• Password protected (whoCanAccess = 1) → access type forced to Anyone with a password, and a password is required to save.
• Email verification (whoCanAccess = 2) → access type forced to Specific people, and at least one recipient email is required to save.
• Any (0) / flag off / no applying policy → no change to existing behavior.

📸 Screenshots

Password protected	Email verification	Email domain validation

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the enforcement of the Send Controls policy's access-control option (whoCanAccess) behind the pm-31885-send-controls flag, including the two follow-up commits that extract earliestRevisionDate into a [Policy] extension and localize the allowed-domain list formatting. The access type resolution (.max() over whoCanAccess, mapping 1 → password / 2 → email verification) is gated by the feature flag, the "Who can view" menu is forced and disabled when enforced, and save validation requires a password or at least one allowed-domain recipient email as appropriate. The recipientEmails refactor to a default single empty row is safe: removeRecipientEmail never empties the array and normalizedRecipientEmails filters empty entries before submission, so dropping the append in accessTypeChanged does not regress the email row. Test coverage is thorough across SendPolicyOptions, SendAccessType, [Policy], PolicyService, the alert extension, state, processor, and view layers.

Code Review Details

• 🎨 : Property named earliestRevisionDate returns a Policy, not a date
  • BitwardenShared/Core/Vault/Models/Domain/Policy.swift:59

Notes considered and cleared during review:

• Domain matching is exact (a policy allowing acme.com rejects user@mail.acme.com) and case-insensitive; consistent with the tests and appears intentional.
• allowedDomains is sourced from the earliest-revision policy that enforces email verification rather than intersecting across multiple orgs. The code comment documents this as deliberate, and the server remains the authoritative enforcement point.
• Forcing state.accessType in loadData for edit mode intentionally overrides the send's stored access type, matching the PR description.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.37%. Comparing base (702231d) to head (c47e0a2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2906      +/-   ##
==========================================
- Coverage   79.38%   79.37%   -0.01%     
==========================================
  Files        1172     1172              
  Lines       74875    74950      +75     
==========================================
+ Hits        59438    59492      +54     
- Misses      15437    15458      +21     

☔ 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.

[claude]

🎨 SUGGESTED: Property name reads as a Date but returns a Policy.

Details and fix

At the call sites this reads as if a date is being returned: policies.earliestRevisionDate?.organizationId (PolicyService.swift:515) and policies.earliestRevisionDate assigned to domainsPolicy (SendPolicyOptions.swift:45). Naming it after the returned type keeps the read accurate:

Suggested change

	var earliestRevisionDate: Policy? {
	var policyWithEarliestRevisionDate: Policy? {

The original private helper it replaced (policyWithEarliestRevisionDate(from:)) carried this clarity; not required, just easier to read at the call site.

[fedemkr]

Looks good, the only ⛏️ is what Claude is suggesting for the name of the property.

[fedemkr]

Nice 🚀