Rules - "Apply to existing unsubmitted expense" gets disabled when rule is reopened.

[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.22.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: #82438
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: Workspace Settings

Action Performed:

Prerequisite: User is an admin of a workspace.
Prerequisite 2: Rules enabled.

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces" > "Rules" > "Add Merchant Rule"
3. In "For expenses with" add any merchant.
4. In "Apply these updates", add any category, description, tag and "Billable" field "On".
5. Enable "Apply to existing unsubmitted expenses"
6. Save the rule.
7. Open the just created rule.
8. Note that "Apply to existing unsubmitted expenses" toggle is disabled.

Expected Result:

"Apply to existing unsubmitted expenses" feature should remain enabled when user saves the rule and reopens it.

Actual Result:

"Apply to existing unsubmitted expenses" feature gets disabled after saving merchant rule and reopening the just created rule.

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: #82438

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @dylanexpensify (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.

[twilight2294]

Proposal

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

When a user creates a merchant rule with the "Apply to existing unsubmitted expenses" toggle enabled, saves it, and then reopens the rule for editing, the toggle is always shown as disabled (off). This creates a confusing UX where the user's previously-set preference appears to be lost.

What is the root cause of that problem?

The toggle state is stored exclusively in local React component state in src/pages/workspace/rules/MerchantRules/MerchantRulePageBase.tsx at line 104:

const [shouldUpdateMatchingTransactions, setShouldUpdateMatchingTransactions] = useState(false);

Because it is hardcoded to false, every time the component remounts (i.e., when the user reopens the rule page), the toggle resets to off — regardless of what the user had previously set.

The useEffect block that pre-populates form fields when editing an existing rule (lines 110–130) initializes all other fields from existingRule data but never calls setShouldUpdateMatchingTransactions(...). This means there is no path by which the toggle can be restored to a non-default state on remount.

Additionally, the CodingRule type in src/types/onyx/Policy.ts has no field for shouldUpdateMatchingTransactions, and the setPolicyCodingRule action in src/libs/actions/Policy/Rules.ts never persists this value. As a result, there is no source of truth to restore the toggle state from on reopen.

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

Since shouldUpdateMatchingTransactions is semantically a "do this retroactively right now" one-shot action flag (not a persistent rule attribute), the most pragmatic fix that matches user expectations is to default the toggle to true when editing an existing rule, rather than always defaulting to false. This matches the intuition that when a user reopens a rule to edit it, they likely want their changes applied retroactively.

In src/pages/workspace/rules/MerchantRules/MerchantRulePageBase.tsx, line 104, change:

// Before:
const [shouldUpdateMatchingTransactions, setShouldUpdateMatchingTransactions] = useState(false);

// After:
const [shouldUpdateMatchingTransactions, setShouldUpdateMatchingTransactions] = useState(isEditing);

This single change means new rule creation keeps the opt-in behavior (toggle starts off), while editing an existing rule pre-enables the toggle — consistent with the expectation that editing a rule should apply those edits retroactively by default.

What alternative solutions did you explore?

A more complete fix would involve: (1) adding a shouldUpdateMatchingTransactions?: boolean field to the CodingRule type in src/types/onyx/Policy.ts, (2) persisting the value in setPolicyCodingRule() in src/libs/actions/Policy/Rules.ts, and (3) reading it back in the useEffect initialization in MerchantRulePageBase.tsx. However, this approach conflicts with the semantic meaning of the toggle as a one-shot action rather than a persistent rule attribute, adding unnecessary complexity for limited benefit.