[PM-39978] Fix compilation errors caused by Item type Send support in…

[mcamirault]

… the SDK

🎟️ Tracking

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

📔 Objective

Tools is adding a new type of Send to support temporary item sharing. The logic hasn't been added to the SDK yet but the new SendType enum has, and this causes compilation errors which are fixed by this PR.

📸 Screenshots

None

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: REQUEST CHANGES

This PR restores compilation after the SDK added SendType.ITEM by extending the exhaustive when expressions across the Send data, state, and UI layers, plus adding SendTypeJson.ITEM and four new strings. The mapping additions are mechanically correct and the network serializer now tolerates type 2 sends instead of failing deserialization. The main concern is that adding ITEM to the SendItemType enum also makes the unimplemented type user-selectable, because the new-Send selection dialog is driven by SendItemType.entries. No test changes accompany the new enum branches.

Code Review Details

• ❌ : Adding ITEM to SendItemType exposes a selectable "Item" row in the new-Send dialog (SendScreen.kt:257 iterates entries), leading to an Add Send form with an empty content section and a failing save
  • app/src/main/kotlin/com/x8bit/bitwarden/ui/tools/feature/send/model/SendItemType.kt:12
• ⚠️ : Hardcoded English "Item Sends are not yet available" reaches the user-facing error dialog via firstValidationErrorMessage
  • app/src/main/kotlin/com/x8bit/bitwarden/data/vault/manager/SendManagerImpl.kt:80-85

Also noted, no action strictly required: an ITEM Send synced from another client renders no content area in ViewSendScreen.kt:302 and AddEditSendContent.kt:138 (empty when branches), and the Item/ItemType placeholder data: String fields are unused.

[claude]

❌ CRITICAL: Adding ITEM here exposes an unimplemented "Item" option in the user-facing new-Send dialog.

Details and fix

SendScreen.kt:257 builds the SelectSendAddType dialog rows from SendItemType.entries:

SendItemType.entries.forEach {
    BitwardenBasicDialogRow(text = it.selectionText(), onClick = { onAddSendSelected(it) })
}

With ITEM added (and selectionText → BitwardenString.item = "Item"), every user now sees a third "Item" row. The path from there is fully reachable and broken:

1. SendViewModel.handleAddSendSelected only special-cases FILE, so ITEM navigates straight to Add Send.
2. AddEditSendViewModel builds SendType.Item(data = ""), and AddEditSendContent.kt:138 renders an empty branch → the form shows name/options/Save but no content field.
3. Tapping Save reaches SendManagerImpl and fails with the hardcoded English "Item Sends are not yet available".

Since this PR is only meant to restore compilation against the new SDK enum, keep ITEM out of the selectable set until the feature exists — e.g. filter the dialog source (SendItemType.entries.filter { it != SendItemType.ITEM }) or gate it behind a feature flag, and mirror that in VaultItemListingViewModel.kt:916.

[claude]

⚠️ IMPORTANT: Hardcoded English string is surfaced directly in a user-facing error dialog.

Details and fix

InvalidJsonResponse.firstValidationErrorMessage falls back to message when validationErrors is null, so this string flows into CreateSendResult.Error(message = ...) and then into AddEditSendViewModel (line 264), which displays result.message verbatim. Users in any locale would see untranslated text.

Prefer failing with an exception so the existing localized generic error is shown:

SendType.ITEM -> IllegalStateException("Item Sends are not supported").asFailure()

That yields CreateSendResult.Error(message = null, error = ...) → generic_error_message, and keeps the developer-facing detail in the throwable instead of the UI.