Expense rule - Tag is not imported correctly when tag is in X: Y format

[applause-bot]

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.4.36-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: #95105
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Enable Rules and Tags.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rules.
3. Click More > Import merchant rules.
4. Upload a file that contains "Updated tag" in X: Y format.
   → Expense rule row shows X, Y instead of X: Y.
5. Open the expense rule.
   → Tag field shows X instead of X: Y.

Expected Result:

In Step 4, expense rule row should show the correct tag, which is X: Y.
In Step 5, Tag field will show X: Y.

Actual Result:

In Step 4, expense rule row shows X, Y instead of X: Y.
In Step 5, Tag field shows X instead of X: Y.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210653_1784289088868.2.mp4

Bug7210653_1784289079464!random_merchants_true_false__1___2_.csv

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7210653

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078201595127246705
• Upwork Job ID: 2078201595127246705
• Last Price Increase: 2026-07-17

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/ae68014242c61a1db7b5ee3fe52be4a104a0e305986de3f4e9c80f34688e3cae

https://platform.applause.com/services/links/v1/external/5f5c7b0f9dafd6360b5e3044b43a0e0866dc7d750b52c71fa1ea4dd3918af7e5

[melvin-bot]

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

[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.

[MelvinBot]

Proposal

What is the root cause of that problem?

Multi-level tags in the app are encoded as levels joined by a bare colon with no spaces (X:Y) — that's exactly what the manual "Add tag" flow produces via trimTag(newTags.join(':')).

The new spreadsheet-import flow does not apply that normalization. ImportedMerchantRulesPage.tsx:176 reads the cell with only an outer .trim() and stores it raw at line 194, so a cell typed as X: Y is persisted verbatim (colon plus a space).

Every display path then splits that string on :, yielding ["X", " Y"] (note the leading space on the second level):

• Rules row shows X, Y — MerchantRulesSection.tsx:61 renders getCommaSeparatedTagNameWithSanitizedColons(rule.tag), which splits on : and joins with , (PolicyUtils.ts:1190).
• Rule detail shows only X — the edit page resolves each level against the policy's real tag lists; level 0 X matches, but level 1 " Y" (with the stray space) matches no real tag, so it's dropped.

The bug is not the display code — it's that the import stores a non-canonical tag string. X: Y was never meant to be a two-level tag; the space makes it one accidentally.

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

Normalize the tag cell at import time so it matches the canonical encoding used everywhere else. In ImportedMerchantRulesPage.tsx, after reading the tag cell, split it on :, trim each level, and re-join with : — mirroring what AddTagPage.tsx:60 already does (trimTag + getTagArrayFromName keep escaped-colon handling consistent). X: Y then becomes the valid X:Y, and both the row and the detail render X: Y correctly.

Notes / edge cases

• Follow the same escaping rules as trimTag/getTagArrayFromName so a single-level tag whose name legitimately contains a colon stays escaped (\:), keeping import and manual creation in sync.
• Worth a quick check that setPolicyCodingRule in src/libs/actions/Policy/Rules.ts doesn't re-mangle the value.
• This is a new, staging-only feature, so no data migration for previously-imported rules is needed.
• Fix is entirely client-side in Expensify/App.

Confidence: High — verified both display symptoms against the code paths and confirmed the canonical join(':') (no space) encoding vs. the raw import store.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96391) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[NicolasBonet]

@MelvinBot implement that