[Due for payment 2026-06-25] [$500] Auto-choose selection for user when the last (and only value) is deleted

[JmillsExpensify]

In the following case:

• Admin delete a value for a field/list on the policy
• The value corresponds to an expense on a draft/outstanding report that hasn't been approved by anyone
• There is only one valid field/list value for the workspace

Then let's automatically select the only possible value on the workspace rather than show a violation and require that someone manually selects what is the only value.

This logic should apply to:

• Categories
• Tags
• Distance rates
• Tax rates

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022036419273592237323
• Upwork Job ID: 2036419273592237323
• Last Price Increase: 2026-06-25

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When an admin deletes a policy field value (category, tag, distance rate, or tax rate) that is used on a draft/outstanding expense, and only one valid value remains for that field on the workspace, the app shows an "out of policy" violation requiring the user to manually select the sole remaining option. Instead, the app should auto-select that last remaining value automatically.

What is the root cause of that problem?

The deletion actions (deleteWorkspaceCategories, deletePolicyTags, deletePolicyDistanceRates, deletePolicyTaxes) trigger violation re-evaluation via pushTransactionViolationsOnyxData (in src/libs/ReportUtils.ts) and ViolationsUtils.getViolationsOnyxData (in src/libs/Violations/ViolationsUtils.ts), which correctly adds violations like categoryOutOfPolicy, tagOutOfPolicy, customUnitOutOfPolicy, and taxOutOfPolicy to affected transactions. However, none of these code paths check whether only one valid option remains — they only flag the violation without auto-correcting the transaction's field value.

There is existing auto-selection logic in MoneyRequestConfirmationList.tsx (lines 957-991) that selects a category/tag when only one enabled option exists, but it only runs during new expense creation and guards against re-firing with checks like !iouCategory. It does not apply to existing transactions after admin deletions.

What changes do you think we should make in order to solve the problem?

The fix should be applied in pushTransactionViolationsOnyxData in src/libs/ReportUtils.ts, since this is the central function called when policy data changes (category/tag deletions/disables). After computing violations for each transaction, add logic to:

1. Categories: After detecting categoryOutOfPolicy, count enabled categories (excluding pending-delete). If exactly 1 remains, push an optimistic TRANSACTION Onyx update setting the transaction's category to that value, and remove the categoryOutOfPolicy violation.

2. Tags: Same approach per tag list — if exactly 1 enabled tag remains in a required tag list and the transaction has a tagOutOfPolicy violation for that list, auto-set the tag and remove the violation.

3. Distance rates: deletePolicyDistanceRates in src/libs/actions/Policy/DistanceRate.ts uses its own violation logic (not pushTransactionViolationsOnyxData). Add similar logic there: after computing CUSTOM_UNIT_OUT_OF_POLICY violations for affected transactions, check if exactly 1 enabled rate remains in the custom unit. If so, push an optimistic transaction update changing comment.customUnit.customUnitRateID and skip adding the violation.

4. Tax rates: deletePolicyTaxes in src/libs/actions/TaxRate.ts currently does NOT call pushTransactionViolationsOnyxData at all. It would need to either (a) be updated to call it, or (b) add inline logic: after deletion, count remaining enabled tax rates (!isDisabled). If exactly 1 remains, push optimistic transaction updates setting taxCode on affected transactions.

The scope condition from the issue should be respected: this auto-selection only applies to transactions on draft or outstanding reports (not yet approved by anyone), which pushTransactionViolationsOnyxData already filters for.

What alternative solutions did you explore? (Optional)

• ViolationsUtils.getViolationsOnyxData approach: Instead of modifying pushTransactionViolationsOnyxData, the auto-selection could be embedded in getViolationsOnyxData itself. However, this function only returns violation Onyx updates — it would need to be refactored to also return transaction updates, which changes its contract and affects all callers (IOU creation, editing, transaction moves).

• Server-side approach: The auto-selection could be handled in the backend command handlers (Auth). However, the current architecture computes violations optimistically on the client, so adding client-side auto-selection is more consistent and gives immediate feedback.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @hoangzinh (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022036419273592237323

[gps949]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When an admin deletes a policy field value (category, tag, distance rate, or tax rate), and the deleted value was the one assigned to a draft/outstanding expense, the app raises an "out of policy" violation. If only one valid value remains for that field on the workspace, the user must manually pick that sole remaining option. The app should auto-select it instead.

What is the root cause of that problem?

The deletion actions (deleteWorkspaceCategories, deletePolicyTags, deletePolicyDistanceRates, deletePolicyTaxes) call pushTransactionViolationsOnyxData (in src/libs/ReportUtils.ts), which iterates over affected transactions and recomputes violations via ViolationsUtils.getViolationsOnyxData. This correctly flags violations like categoryOutOfPolicy, tagOutOfPolicy, customUnitOutOfPolicy, and taxOutOfPolicy, but never pushes optimistic transaction updates to auto-correct the field value when only one valid option remains.

The function pushTransactionViolationsOnyxData only pushes ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS updates. There is no companion logic to also push ONYXKEYS.COLLECTION.TRANSACTION updates when a single valid option can be auto-selected.

What changes do you think we should make in order to solve the problem?

Modify pushTransactionViolationsOnyxData in src/libs/ReportUtils.ts (around line 2079) to add auto-selection logic after violations are computed for each transaction. The function already has access to optimisticCategories, optimisticTagLists, and optimisticPolicy (the merged state after deletion), so we can count enabled options directly.

Concrete changes inside the for...of loop (after getViolationsOnyxData is called):

1. Categories — After computing optimisticViolations, check if any categoryOutOfPolicy violation exists. If so, count enabled categories from optimisticCategories (filtering enabled === true and pendingAction !== 'delete'). If exactly 1 remains, push an optimistic ONYXKEYS.COLLECTION.TRANSACTION update setting category to that value, and filter out the categoryOutOfPolicy violation from optimisticViolations.value before pushing it.

2. Tags — Same pattern per tag list: check for tagOutOfPolicy violations, count enabled tags in each tag list from optimisticTagLists, and auto-set if exactly 1 remains.

3. Distance rates — deletePolicyDistanceRates in src/libs/actions/Policy/DistanceRate.ts uses its own inline violation logic rather than pushTransactionViolationsOnyxData. Add similar "count remaining enabled rates" logic there: after flagging CUSTOM_UNIT_OUT_OF_POLICY, check if exactly 1 enabled rate remains in the custom unit. If so, push an optimistic transaction update to comment.customUnit.customUnitRateID and skip the violation.

4. Tax rates — deletePolicyTaxes in src/libs/actions/TaxRate.ts does not call pushTransactionViolationsOnyxData. It needs to be updated to either call it (preferred, for consistency) or add inline logic: after deletion, count remaining enabled tax rates (!isDisabled); if exactly 1 remains, push optimistic transaction updates setting taxCode on affected draft/outstanding transactions.

Key implementation details:

• The auto-selection only applies to draft/outstanding reports — pushTransactionViolationsOnyxData already filters for these via policyData.reports.
• Failure data must revert both the transaction field change and the violation removal, so each auto-corrected transaction needs a failureData entry restoring the original category/tag/taxCode/customUnitRateID value and the original violations.
• The onyxData type parameter of pushTransactionViolationsOnyxData must be widened to also include typeof ONYXKEYS.COLLECTION.TRANSACTION so it can push transaction updates alongside violation updates.

What alternative solutions did you explore? (Optional)

• Embedding auto-selection in ViolationsUtils.getViolationsOnyxData: This would require changing its return type to include both violation and transaction updates, breaking its single-responsibility contract and impacting all callers (IOU creation, editing, transaction moves). The action-level approach is more surgical.
• Separate useEffect/subscriber approach: Watching for violation changes in the UI layer and auto-correcting. This introduces race conditions and extra re-renders — the optimistic update path is cleaner and gives instant feedback.

Contributor details:

• Timezone: UTC+8
• Availability: Flexible hours, can start immediately

[mukhrr]

@JmillsExpensify can you pls assign me here as follow up of #84361?! Thanks