Expense - Category inline field is clickable and opens a blank list when categories are disabled

[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.62-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83127
Email or phone of affected tester (no customers): ijsndonjsodnisjdosj@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:

Precondition:

• Create two workspaces - A and B.
• Disable Categories in workspace A.

1. Go to staging.new.expensify.com
2. Create an expense in workspace A.
3. Create an expense with category in workspace B.
4. Go to Spend > All expenses.
5. Click Category field on workspace A's expense (Categories are disabled).

Expected Result:

Category field should not be clickable because categories are disabled.

Actual Result:

Category field is clickable and opens a blank list when categories are disabled.

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

[melvin-bot]

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

[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: #83127 - "Add inline editing to transaction table cells (date, merchant, description, category, amount)" by @mohammadjafarinejad (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #83127 introduced a missing guard for the workspace-level areCategoriesEnabled flag in the canEditCategory permission check, causing the category cell to be clickable even when categories are disabled in the workspace. The fix is straightforward — add policy?.areCategoriesEnabled to the condition — but reverting is safer given the size and scope of this PR.

Assigned: @mohammadjafarinejad (PR author), @ahmedGaber93, @puneetlath (approving reviewers) from PR #83127
Labels: DeployBlockerCash kept (frontend App bug). No label changes made.

Details

Evidence

• The issue reports that the Category inline field is clickable and opens a blank list when categories are disabled in workspace A.
• PR feat: Add inline editing for tables on desktop #83127 introduced the EditableCell component and the getTransactionEditPermissions function in TransactionInlineEdit.ts, which computes canEditCategory.
• The canEditCategory computation (line 351-352 of TransactionInlineEdit.ts) is:

  canEditCategory: (isPolicyExpenseChat &&
    (!!categoryForDisplay || hasEnabledOptions(policyCategories ?? {}))) ||
    (isUnreported && (!policy || hasEnabledOptions(policyCategories ?? {})));

• This checks hasEnabledOptions(policyCategories) — whether individual category records have enabled: true — but does not check policy?.areCategoriesEnabled, which is the workspace-level toggle that disables the entire Categories feature.
• When a workspace has Categories disabled (areCategoriesEnabled = false), the individual category records may still have enabled: true on their entries, causing hasEnabledOptions to return true and canEditCategory to be incorrectly set to true.
• The EditableCell component then renders the cell as a PressableWithFeedback (clickable) instead of a non-pressable View.
• Clicking opens CategoryPickerModal, which shows a blank list because the picker respects the areCategoriesEnabled flag and loads no categories.

Verification

• Affected file: src/libs/actions/TransactionInlineEdit.ts (the getTransactionEditPermissions function)
• Confirmed PR modifies this file: Yes — PR feat: Add inline editing for tables on desktop #83127 introduced this file entirely.
• PR merge date: 2026-04-21, consistent with the bug appearing in staging version 9.3.62-1.
• Supporting evidence: The correct pattern is already used elsewhere in the codebase. For example, src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx line 111 correctly combines both checks:

  const areCategoriesEnabled =
    areSelectedTransactionsExpenses &&
    !!policy?.areCategoriesEnabled &&
    hasEnabledOptions(policyCategories ?? {});

Root Cause

getTransactionEditPermissions in TransactionInlineEdit.ts computes canEditCategory without checking policy?.areCategoriesEnabled. It only checks whether individual category options are enabled (hasEnabledOptions), but misses the top-level workspace switch. The fix requires adding !!policy?.areCategoriesEnabled && to the condition on line 351-352. Since this is a new file introduced entirely by PR #83127 and only exists on staging, reverting is the cleanest resolution.