Expense - Tax field present in cross policy bulk edit, despite one WS having taxes 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.34.0
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: #82948
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

Prerequisite: Account has two workspaces.
Prerequisite 2: Workspace 1 has taxes enabled and workspace 2 has taxes disabled.

1. Open the Expensify app.
2. Open a workspace with taxes enabled.
3. Create a manual expense and select any tax rate during creation.
4. Navigate to a different workspace with taxes disabled.
5. Create another manual expense.
6. Navigate to "Reports" > "Expenses"
7. Select both expenses, tap on dropdown menu and select "Edit Multiple"
8. Note that "Tax Rate" field is available despite one of the expenses not having taxes enabled.
9. Tap on "Tax Rate"
10. Note that all the taxes from Workspace 1 are displayed.

Expected Result:

"Tax rate" field should not be available during cross policy bulk edit, if one of the workspaces has "Taxes" disabled.

Actual Result:

"Tax Rate" field is available and editable during cross policy bulk edit, despite one of the workspaces having "Taxes" disabled.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[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: #82948 - "Reapply "Feat: bulk edit multiple"" by @pasyukevich (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

The issue is straightforward to fix and a revert would remove the entire bulk edit feature. The fix requires checking if tax tracking is enabled for ALL workspaces involved in the bulk edit, not just the active workspace.

Labels: This is reproducible only on staging (not in production as this is a new feature), and the bug is in the App repository. Therefore, I am removing the DeployBlockerCash label as this does not block the mobile app deploy, but keeping DeployBlocker for the backend/web deploy.

📋 Detailed Analysis

Evidence

PR #82948 introduced the bulk edit multiple expenses feature. The issue was explicitly linked to this PR by melvin-bot in the first comment. The bug appears when:

1. User has two workspaces
2. Workspace 1 has taxes enabled
3. Workspace 2 has taxes disabled
4. User selects expenses from both workspaces and opens "Edit Multiple"
5. Tax Rate field appears and shows taxes from Workspace 1

Verification

I examined the code in /home/runner/_work/App/App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx lines 87-89:

const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && !!policy?.tax?.trackingEnabled;
const areCategoriesEnabled = !!policy?.areCategoriesEnabled && hasEnabledOptions(policyCategories ?? {});
const areTagsEnabled = !!policy?.areTagsEnabled && hasEnabledTags(policyTagLists);

The policy variable comes from getSearchBulkEditPolicyID() which returns the active policy ID when expenses are from different workspaces. This means it only checks ONE workspace for tax tracking.

Compare this to the correct pattern used for billable/reimbursable fields (lines 72-78):

const areSelectedTransactionsBillable = selectedTransactionContexts.every(
    ({transaction, transactionPolicy}) => transactionPolicy?.disabledFields?.defaultBillable === false || !!transaction.billable,
);

const areSelectedTransactionsReimbursable = selectedTransactionContexts.every(
    ({transaction, report, transactionPolicy}) => !isIOUReport(report) && transactionPolicy?.disabledFields?.reimbursable === false && !isManagedCardTransaction(transaction),
);

These correctly use .every() to check ALL transactions policies.

Root Cause

The isTaxTrackingEnabled logic only checks a single workspace policy for tax tracking, rather than verifying that ALL selected expenses belong to workspaces with tax tracking enabled. When doing cross-policy bulk edit:

1. If the active workspace has taxes enabled, the tax field shows
2. But some selected expenses may be from a workspace with taxes disabled
3. This allows editing tax on expenses that should not have tax fields

The fix should check that ALL involved workspaces have tax tracking enabled, similar to the billable/reimbursable pattern:

const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && selectedTransactionContexts.every(
    ({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled
);