[Due for payment 2026-04-02] [Due for payment 2026-04-01] Expense - Unable to click on checkbox to deselect category when selected category is not valid

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.43-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85852
Email or phone of affected tester (no customers): sdjoinjsdoisjniodjnosj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense with category.
4. Go to workspace settings > Categories.
5. Delete the category used in Step 3.
6. Go back to workspace chat.
7. Open the report.
8. Click Category.
9. Hover over the selected category.
   → The cursor is not disabled so user can click to deselect it - Expected.
10. Click on the checkbox next to the disabled category.

Expected Result:

The checkbox should not be disabled so that user can click on the checkbox to deselect it.

Actual Result:

The checkbox is disabled. User cannot click on the checkbox to deselect it.
Only the row is enabled. There is inconsistency in the row and checkbox when selected category is no longer valid.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #85852

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85852 - "Pass disabled prop to Checkbox in RadioListItem for parent categories" by @MelvinBot (High confidence)
Related Issues: #85848 (original issue that PR #85852 was fixing)

Recommendation: REVERT

PR #85852 should be reverted to restore the ability for users to deselect invalid/deleted categories. While the PR correctly fixed the issue of parent categories having clickable checkboxes in multi-level hierarchies, it inadvertently broke the ability to deselect categories that are no longer valid.

Labels: Keeping DeployBlockerCash (App deploy is blocked). This is a frontend bug that requires reverting an App PR.

Detailed Analysis

Evidence

PR #85852 added the disabled={!!isDisabled} prop to the Checkbox component in RadioListItem.tsx (line 51). This change was merged on 2026-03-24 at 00:17:05 UTC, which aligns with when this bug appeared on staging.

The issue is reproducible on staging but not production, confirming it was introduced in the current staging deploy (version 9.3.43-0).

Verification

The PR modifies src/components/SelectionList/ListItem/RadioListItem.tsx, which is the exact component used by CategoryPicker to display category selections. The change passes the isDisabled prop from the list item to the Checkbox component.

When a category is deleted, the CategoryOptionListUtils.ts code (line 123) sets enabled: false for selected-but-deleted categories. This causes isDisabled to be true (line 48), which now disables the checkbox due to PR #85852.

Root Cause

The logic in PR #85852 was designed to disable checkboxes for parent categories in multi-level hierarchies (e.g., when you have "A: B: C", only "A: B: C" should be selectable, not "A" or "A: B"). However, the same isDisabled flag is also used for selected categories that are no longer valid/enabled.

The issue is that there are two different types of "disabled" states:

1. Parent categories: Should have disabled checkboxes (cannot be selected)
2. Invalid selected categories: Should have enabled checkboxes (must be deselectable)

PR #85852 treats both cases the same way, disabling the checkbox in both scenarios. This prevents users from deselecting invalid categories, which is the bug reported in #86261.

Fix Strategy

After reverting PR #85852, the original issue #85848 will need to be addressed with a more nuanced approach that distinguishes between parent categories (which should have disabled checkboxes) and invalid selected categories (which should remain clickable for deselection).

[OSBotify]

Investigation Summary - LABEL UPDATE

No label changes needed. The issue correctly has only DeployBlockerCash label, which is appropriate for a frontend bug that blocks the App deploy. The label should remain in place until PR #85852 is reverted and the fix is verified.

[MarioExpensify]

Checking if #85852 is the root cause.

[MelvinBot]

Proposal

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

When a category used on an expense is deleted from workspace settings and the user opens the category picker, the deleted category appears as selected but disabled. The user can click the row to deselect it, but clicking the checkbox itself does nothing because it is disabled. This is inconsistent — the row and checkbox should behave the same.

What is the root cause of that problem?

PR #85852 added disabled={!!isDisabled} to the Checkbox in RadioListItem.tsx (line 51) to fix parent multi-level categories showing enabled checkboxes. However, this introduced an inconsistency with how BaseListItem handles the disabled state.

BaseListItem.tsx at line 167 intentionally keeps disabled-but-selected items interactive:

disabled={isDisabled && !item.isSelected}

This means when isDisabled=true and item.isSelected=true, the row remains clickable so users can deselect a deleted/invalid category. But the Checkbox uses disabled={!!isDisabled} unconditionally, so when isDisabled=true, the checkbox is always disabled regardless of selection state.

The data flow for a deleted-but-selected category:

1. getCategoryListSections marks it with enabled: false, isSelected: true
2. getCategoryOptionTree converts this to isDisabled: true, isSelected: true
3. BaseListItem renders the row as clickable (disabled = true && !true = false)
4. But the Checkbox renders as disabled (disabled = !!true = true)

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

In src/components/SelectionList/ListItem/RadioListItem.tsx, change the Checkbox's disabled prop to match BaseListItem's pattern — account for the selected state:

Change disabled={!!isDisabled} to disabled={!!isDisabled && !item.isSelected}

And update the useMemo dependency array to include item.isSelected (which is already present).

This ensures:

• Parent categories (isDisabled=true, isSelected=false): checkbox stays disabled (original fix preserved)
• Deleted-but-selected categories (isDisabled=true, isSelected=true): checkbox becomes enabled so user can click it to deselect

What alternative solutions did you explore? (Optional)

An alternative would be to handle this in the Checkbox component itself or in CategoryOptionListUtils.ts by not marking selected categories as disabled. However, modifying RadioListItem to match the existing BaseListItem pattern is the most minimal and consistent fix — it aligns both the row and checkbox behavior using the same logic.

---

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.