[PM-40534] feat: Restrict Send creation flow when only one Send type is allowed - #7249
Conversation
github-actions
Bot
added
app:password-manager
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE Reviewed the Send creation flow restriction: the new Code Review Details
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## PM-40528-send-controls-precedence-enforcement #7249 +/- ##
=================================================================================
+ Coverage 85.75% 85.99% +0.24%
=================================================================================
Files 937 1027 +90
Lines 67000 67761 +761
Branches 9794 9833 +39
=================================================================================
+ Hits 57453 58271 +818
+ Misses 6053 5973 -80
- Partials 3494 3517 +23
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Updates the Send creation UX so that when an org’s SendControls policy restricts Send creation to a single type (Text or File), tapping “+” skips the type picker and routes directly through the same restriction checks that would have applied after a picker selection. It also hides the “Types” filter section on the Send list when filtering is meaningless (only one allowed type).
Changes:
- Add a
SendTypeJson -> SendItemTypemapper and unit tests for bothSendTypeandSendTypeJsonmappings. - Teach
SendViewModelto derive asingleAllowedSendTypefromEffectiveSendPolicy.allowedSendTypesand use it to (a) skip the type picker on “+” and (b) control whether the Types filter section is shown. - Update Compose UI to conditionally render the Types filter section, with Compose test coverage.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| app/src/test/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/util/SendTypeExtensionsTest.kt | Adds coverage for toSendItemType() mapping for both SendType and SendTypeJson. |
| app/src/test/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/SendViewModelTest.kt | Adds tests for “+” behavior under single-allowed-type policies and for live policy updates affecting UI state. |
| app/src/test/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/SendScreenTest.kt | Verifies the Types filter section is shown/hidden based on singleAllowedSendType. |
| app/src/main/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/util/SendTypeExtensions.kt | Introduces SendTypeJson.toSendItemType() mapping. |
| app/src/main/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/SendViewModel.kt | Implements single-allowed-type derivation, skips picker on “+” when applicable, and threads state into UI. |
| app/src/main/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/SendScreen.kt | Plumbs shouldShowTypesSection into SendContent. |
| app/src/main/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/SendContent.kt | Conditionally renders the Types filter header + rows based on shouldShowTypesSection. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| private val EffectiveSendPolicy.singleAllowedSendType: SendItemType? | ||
| get() = allowedSendTypes | ||
| ?.singleOrNull() | ||
| ?.toSendItemType() |
There was a problem hiding this comment.
❓ QUESTION: How should an empty allowedSendTypes list be treated?
Details
singleOrNull() returns null for both an empty list and a list with 2+ entries, so allowedSendTypes = [] is handled identically to null (no restriction): the type picker is shown and both Text and File remain creatable.
If the server can ever emit [] for a SendControls policy where the admin selected no types, this would be a permissive fallback. If [] is not reachable (or genuinely means "unrestricted"), no change is needed — just confirming the intent, since the KDoc only documents the null case.
There was a problem hiding this comment.
Server always sends the list with at least one type. It is required.
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-40534
📔 Objective
When an org's SendControls policy only allows one Send type, tapping "+" now goes straight to that type's editor instead of asking Text or File first. Picking from a list of one isn't much of a choice.
The skip runs through the same checks the picker did, so nothing gets bypassed on the way through. A File-only org on a free account still gets the "Premium required" dialog rather than landing in an editor it can't use.
The "Types" filter rows on the Send list are hidden in that case too, since filtering by category only makes sense when there's more than one.
With both types allowed, no restriction, or the flag off, everything behaves as it did. That falls out on its own: allowedSendTypes is null in all of those cases, so there's no extra flag check anywhere in this change.
Also plumbs allowedSendTypes through to the Send screen, which PM-40528 hadn't done yet, and adds the SendTypeJson to SendItemType mapper that didn't exist.
Stacked on #7239 (PM-40528), so this targets that branch rather than main.
📸 Screenshots
Screen.Recording.2026-08-06.at.18.51.22.mov