[PM-40460] feat: Enforce Send type restriction via Send Controls policy

[matt-livefront]

🎟️ Tracking

PM-40460

📔 Objective

Enforce the new restrict Send type option of the Send Controls policy (pm-31885-send-controls). When an organization restricts Send creation to a single type, non-owner/non-admin members should only be able to create that type — with no chooser to pick text vs. file — and the "Types" filter should disappear from the Send list.

The policy is delivered on the existing sendControls policy via a new allowedSendTypes data key: an array of SendType raw values (0 = text, 1 = file). [0, 1] (or a missing key) means both types are allowed; [0] restricts to text-only and [1] to file-only. This builds directly on the consolidated SendPolicyOptions (#2877) and the access-control enforcement added in #2906.

📸 Screenshots

Text Only	File Only	Both
send.text.only.mov	send.file.only.mov	send.both.mov

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the enforcement of the restrict-Send-type option of the Send Controls policy. SendPolicyOptions now resolves enforcedSendType from the allowedSendTypes policy data key, an includeTypesSection flag is threaded through SendRepository.sendListPublisher, and restrictedSendType is wired into SendListState/SendListProcessor/SendListView so restricted members bypass the text/file chooser and lose the "Types" filter. Type raw-value mapping (text=0, file=1), missing/empty/duplicate/unknown values, and the most-restrictive resolution across multiple policies are handled and covered by tests; all sendListPublisher call sites and MockSendRepository are updated with the signature change.

Code Review Details

• ❓ : Type restriction is enforced only on the Send list; the share extension can still create a Send of the restricted-away type
  • BitwardenShared/UI/Tools/Send/Send/SendList/SendListState.swift:31

Notes considered and intentionally not raised as findings:

• An empty allowedSendTypes array resolves to unrestricted, matching the documented behavior for a missing key and explicitly covered by a test.
• The .task(id: store.state.restrictedSendType) restart means the "Types" section may render for the brief window before loadData resolves the policy; the id-based restart correctly re-subscribes with includeTypesSection: false.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.66%. Comparing base (c47e0a2) to head (5f54987).

Additional details and impacted files

@@                               Coverage Diff                               @@
##           matt/PM-40248-send-controls-access-controls    #2909      +/-   ##
===============================================================================
+ Coverage                                        79.37%   81.66%   +2.28%     
===============================================================================
  Files                                             1172     1049     -123     
  Lines                                            74950    67675    -7275     
===============================================================================
- Hits                                             59492    55264    -4228     
+ Misses                                           15458    12411    -3047     

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

❓ QUESTION: Is the share extension path intentionally left out of the type restriction?

Details

The restriction is resolved and applied only in SendListProcessor/SendListView, so the share-extension entry point still creates a Send of whichever type the shared content is. SendItemCoordinator.showAddItem(content:) sets state.type = .file for .file content and .text for .text content, and AddEditSendItemProcessor.loadData() applies sendPolicyOptions.enforcedAccessType but not enforcedSendType:

state.sendPolicyOptions = await services.policyService.getSendPolicyOptions()
if let enforcedAccessType = state.sendPolicyOptions.enforcedAccessType {
    state.accessType = enforcedAccessType
}

So a member restricted to text-only can still share a file through the iOS share sheet and save it as a file Send, while isSendDisabled and enforcedAccessType from the same policy are honored on that screen. If this is deferred to a follow-up ticket, no change needed here — just want to confirm it isn't an oversight.