[Due for payment 2026-09-25] Bulk editing a parent level of a multi-level tag clears child tag values in New Expensify

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @nicollyrodrigues-max
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Description:

When using Edit multiple in New Expensify to update only the Cost Center (parent tag level) across multiple expenses, the existing values for the child tag levels (Indication and Phase) are cleared, even though those fields were not modified. In Classic Expensify, updating a single field in bulk preserved the values of the other tag fields.

Action Performed:

1. Log in to New Expensify
2. Open report
3. Select all expenses in the report
4. Click Edit multiple
5. Update only the Cost Center field (parent tag level)
6. Save the changes
7. Open the edited expenses and review the tag values

Expected Result:

Only the Cost Center (parent tag level) should be updated. The existing Indication and Phase values (child tag levels) on each expense should remain unchanged.

Actual Result:

After saving, the Indication and Phase values (child tag levels) are cleared from all selected expenses, despite those fields not being edited.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082490455225634325
• Upwork Job ID: 2082490455225634325
• Last Price Increase: 2026-07-29

Issue Owner

Current Issue Owner: @sobitneupane

[MelvinBot]

Proposal

Problem

Using Edit multiple to change only the parent level of a multi-level tag (e.g. Cost Center) wipes out the child levels (Indication, Phase) on every selected expense, even though those fields weren't touched. Single-expense editing preserves them correctly, and Classic Expensify preserved them in bulk too.

Root Cause

Bulk edit builds one flat tag string in the UI and overwrites it verbatim onto every selected transaction, instead of merging the change into each transaction's own multi-level tag.

1. The bulk tag page seeds the editor from getCommonDependentTag(...) — only the common prefix shared by all selected transactions — not each transaction's full tag. When the expenses share a parent but differ on children, the children are already dropped from the base before any edit. See SearchEditMultipleTagPage.tsx:40-64 and SearchEditMultipleUtils.ts:15-43.
2. The resulting single string is applied to all transactions at BulkEdit.ts:232-234, and TransactionUtils/index.ts:817-818 does a flat updatedTransaction.tag = transactionChanges.tag — a full overwrite, not a per-level merge.

The single-expense path avoids this because it feeds each transaction's own full tag into the same helper (IOURequestStepTag.tsx:102,147-156), so untouched levels survive.

Solution

Apply the tag edit per-transaction instead of precomputing one flat string:

• In the bulk draft, store the edited level index and the selected value for the changed level (rather than a single finished tag string).
• At apply time in BulkEdit.ts, reconstruct the tag for each transaction by running the existing getUpdatedTransactionTag / insertTagIntoTransactionTagsString merge against that transaction's current full tag at the edited tagListIndex, preserving levels the user didn't change.

Design note — dependent vs. independent tags

For independent multi-level tags this is an unambiguous bug: changing the parent must keep the children.

For dependent tags, getUpdatedTransactionTag intentionally clears children when a parent changes (TagsOptionsListUtils.ts:300-329), because a child valid under the old parent may be invalid under the new one. The reporter's expectation (preserve children) matches Classic and matches the independent-tag case; confirm whether the affected policy uses dependent or independent tags so the fix targets the right behavior. Either way, the per-transaction merge is the correct structural fix — bulk edit should never overwrite untouched levels with a shared common-prefix string.

Secondary bug to fold in: at SearchEditMultipleTagPage.tsx:43, currentTag is derived from draftTag ?? '' instead of the common tag, so on the first interaction deselect detection (isSelectedTag) never fires.

Related issues

• [Due for payment 2026-08-08] [$250] Dependent tags-Second level tag (Region) row is empty after selecting first level tag #94005 — Dependent tags: second-level row empty after selecting first level (adjacent multi-level tag area, not a duplicate).

---

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

[j3ffffff]

VERDICT: POST
ROOT_CAUSE_ONELINER: When bulk-editing only the parent tag level, getCommonDependentTag strips per-transaction child tag levels from the draft's base string, so the resulting changes.tag contains only the parent level, which updateMultipleMoneyRequests then applies uniformly to all transactions, overwriting each one's individual child tag values.
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022082490455225634325

[melvin-bot]

@sobitneupane Eep! 4 days overdue now. Issues have feelings too...

[sobitneupane]

@MelvinBot Could you share a bit more detail on how you are planning to implement this?

[MelvinBot]

Sure. The core change is to stop precomputing one tag string in the bulk-edit page and applying it to every expense, and instead reconstruct the tag per-transaction at apply time against each expense's own current tag. A single shared string fundamentally can't represent expenses that share a parent but differ on children, which is the whole bug.

The two changes

1. Store the edit intent, not a finished tag string, in the bulk draft

Today SearchEditMultipleTagPage.saveTag runs getUpdatedTransactionTag against the common prefix (transactionTag, seeded from getCommonDependentTag at line 42) and saves the finished string into the draft's tag. By that point each expense's child levels are already gone.

Instead, save just what the user changed into the bulk-edit draft:

• tagListIndex — which level was edited
• the selected value (item.searchText ?? '', empty = deselect)

The picker's own selectedTag/transactionTag props can keep being seeded from commonDependentTag for display — that only drives which row is highlighted.

2. Reconstruct per-transaction in updateMultipleMoneyRequests

Replace the flat overwrite at BulkEdit.ts:238-239:

if (changes.tag && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAG)) {
    transactionChanges.tag = changes.tag;
}

with a call that rebuilds the tag from that transaction's own full tag (transaction.tag), reusing the exact helper the single-expense path uses:

transactionChanges.tag = getUpdatedTransactionTag({
    transactionTag: transaction.tag ?? '',
    selectedTagName,                       // from the draft
    currentTag: getTagArrayFromName(transaction.tag ?? '').at(tagListIndex) ?? '',
    tagListIndex,                          // from the draft
    policyTags: <this txn's policyTags>,
    hasDependentTags: <this txn's policy>,
    hasMultipleTagLists: transactionPolicy?.hasMultipleTagLists ?? false,
});

The loop already resolves transactionPolicy per transaction, so hasDependentTags/hasMultipleTagLists come from the expense's real workspace rather than the bulk policy. Because getUpdatedTransactionTag routes independent tags through insertTagIntoTransactionTagsString — which replaces only tagArray[tagIndex] and leaves the other levels intact — the untouched Indication/Phase levels survive on each expense.

Dependent vs. independent tags

Worth flagging so we lock in expected behavior before coding: for independent multi-level tags this restores the reporter's/Classic expectation (edit parent → children preserved). For dependent tags, getUpdatedTransactionTag deliberately clears children when a parent changes, since a child valid under the old parent may be invalid under the new one — but the per-transaction merge now runs that logic against each expense's real tag rather than a lossy shared prefix, which is the correct structural behavior either way. Can you confirm the affected policy uses independent tags? That's the case where "children preserved" is unambiguously right.

Also fold in

The stale-currentTag seeding at SearchEditMultipleTagPage.tsx:43 (currentTag derived from draftTag ?? '') — on the first interaction draftTag is empty, so deselect detection never fires. With change #1 removing the precomputed string from the draft, this seeding should come from commonDependentTag instead.

Testing

Single-expense tag editing already uses this exact helper against the full tag (IOURequestStepTag), so this brings bulk edit in line with it. I'd cover it with a unit test on updateMultipleMoneyRequests: two selected expenses sharing Cost Center but differing on Indication/Phase, edit only the parent, assert each expense's children are unchanged (independent) and correctly cleared (dependent).

---

Next Steps: Reply with @MelvinBot implement [this](https://github.com/Expensify/App/issues/97356) to open a draft PR, or @MelvinBot <feedback> to refine.

[sobitneupane]

@MelvinBot Does this work for more than 2 levels too? Like if we have 3 levels and the middle tag changes, will it handle that properly?