[PM-41028] feat: Restrict View Send screen for policy non-compliant Sends

[matt-livefront]

🎟️ Tracking

PM-41028

📔 Objective

• Add SendPolicyOptions.isSendTypeRestricted(for:) to determine whether an existing Send violates the active Send Controls policy (restricted type takes priority over restricted access type/deletion date/hide-email).
• View Send screen now hides the send-link (copy/share) section and the floating edit button, and shows an ActionCard "Organization policy restriction" banner for non-compliant Sends, with copy varying by violation: restricted text type, restricted file type, or restricted fields (with a "Make a copy" action).
• File Sends never offer "Make a copy" (an existing attachment can't be carried into a new Send), regardless of which policy field is actually violated.
• "Make a copy" opens a new Send pre-filled from the original Send's data, adjusted to comply with the active policy via the existing AddEditSendItemProcessor policy-enforcement logic.

📸 Screenshots

Send Text Restriction

Send File Restriction

Send Restricted Field

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: REQUEST CHANGES

Reviewed the View Send screen restrictions for policy non-compliant Sends: the new SendPolicyOptions.isSendTypeRestricted(for:) helper, ViewSendItemState's disabled/banner/copy computed properties, the .makeCopy action and .copy(SendView) add-send route, and the AddEditSendItemState(copyingFrom:) initializer. Test coverage is thorough across state, processor, coordinator, snapshot, and ViewInspector layers. Two correctness concerns were found: the restriction UI keys off the user-controlled disabled flag with no Send Controls gate, and the "Make a copy" flow can produce a Send that still violates the hide-email restriction.

Code Review Details

• ⚠️ : isDisabled treats every deactivated Send as a policy violation, and isn't gated by the .sendControls flag — user-deactivated Sends get a false "Organization policy restriction" banner and lose the edit FAB
  • BitwardenShared/UI/Tools/Send/SendItem/ViewSendItem/ViewSendItemState.swift:44-47
• ⚠️ : init(copyingFrom:) carries over hideEmail even when the policy disables it, and the field is hidden, so the copy stays non-compliant with no way to fix it
  • BitwardenShared/UI/Tools/Send/SendItem/AddEditSendItem/AddEditSendItemState.swift:278

[claude]

⚠️ IMPORTANT: isDisabled treats every deactivated Send as a policy violation, with no Send Controls gate.

Details and fix

sendView.disabled is the user-controlled "Deactivate this Send" flag, not a policy-violation marker. It's round-tripped through AddEditSendItemState (isDeactivateThisSendOn: sendView.disabled → disabled: isDeactivateThisSendOn) and already surfaced independently in the Send list as DisabledSendIcon.

Consequences for a Send the user deactivated themselves (e.g. from the web vault):

• The banner claims "Organization policy restriction" for a Send that violates no policy.
• sendLink and the edit FAB are both hidden, so the Send can no longer be re-activated or edited from iOS.

This also isn't gated by the .sendControls feature flag. getSendPolicyOptions() returns empty options when the flag is off, so isSendTypeRestricted is false, but isDisabled never consults the flag or the policy — meaning the new banner and the hidden edit button ship to all users with a deactivated Send while the feature is still flagged off.

Consider gating on the Send Controls policy actually applying (flag enabled and non-default sendPolicyOptions), or deriving non-compliance from comparing the Send's fields to sendPolicyOptions rather than from disabled alone.

[claude]

⚠️ IMPORTANT: The copy carries over hideEmail even when policy disables it, so the new Send is still non-compliant.

Details and fix

Hide-email is one of the restricted fields that makes a Send non-compliant, and it's exactly the case where "Make a copy" is offered (canMakeCopy is true for any disabled text Send whose type isn't restricted).

But the copy is never corrected for it:

• AddEditSendItemProcessor.loadData() only overrides accessType and policyEnforcedDeletionDate.
• shouldShowHideEmailField is false while the Send Controls policy disables hide-email, so the toggle isn't rendered.

The result is a new Send saved with hideEmail: true under a policy that forbids it, with no UI affordance for the user to fix it.

// AddEditSendItemProcessor.loadData()
if state.sendPolicyOptions.isHideEmailDisabled {
    state.isHideMyEmailOn = false
}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.98%. Comparing base (4a790d9) to head (15181ef).

Additional details and impacted files

@@                                  Coverage Diff                                   @@
##           matt/PM-38792-send-controls-restrict-deletion-days    #2920      +/-   ##
======================================================================================
+ Coverage                                               78.88%   78.98%   +0.10%     
======================================================================================
  Files                                                    1162     1168       +6     
  Lines                                                   74715    75039     +324     
======================================================================================
+ Hits                                                    58939    59270     +331     
+ Misses                                                  15776    15769       -7     

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