Spend - Negated filter does not appear in Save view RHP

[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.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: #95023
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: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Spend > Expenses.
3. Click Search button on the top right.
4. Type -status:draft and press Enter.
5. Click Save.

Expected Result:

-status:draft should appear in Save view RHP.

Actual Result:

-status:draft does not appear in Save view RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7207992_1784031660057.6.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7207992

[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/74db65ff4910ab9b6ae8379e6f66fa704a15b19a9276beb5b3364bdef389e3ed

[melvin-bot]

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

[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

Deploy blocker introduced by #95023 ("Allow workspace and status filter to be negatable"). Search results are correct, but a negated status/workspace filter is silently dropped from the Save Search RHP.

What is the root cause of that problem?

A negated filter like -status:draft is parsed and stored under a separate *Not form key (statusNot, and policyIDNot for workspace) in buildFilterFormValuesFromQuery — that part works.

The Save RHP builds its "Applied filters" list with mapFiltersFormToLabelValueList, which resolves each form key's label from FILTER_VIEW_MAP:

const label = key in FILTER_VIEW_MAP ? FILTER_VIEW_MAP[key].labelKey : undefined;
const value = getDisplayValue(...);
if (label && value && ...) { filters.push(...) }   // dropped when label is undefined

SearchUIUtils.ts:5568-5571

But FILTER_VIEW_MAP only has entries for the positive keys (status, policyID) — it has no statusNot / policyIDNot entries. So for a negated filter the label resolves to undefined, the if (label && value) guard fails, and the row is never pushed. The non-negated status:draft appears because its key status does have a FILTER_VIEW_MAP entry.

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

1. Add FILTER_VIEW_MAP entries for the negated keys (FILTER_KEYS.STATUS_NOT, FILTER_KEYS.POLICY_ID_NOT), reusing the common.status / workspace.common.workspace labels — ideally with a visual "not"/exclusion indicator so the RHP shows it's a negation.
2. Extend getDisplayValue so the STATUS value-formatting branch also matches STATUS_NOT (currently only status is translated; policyIDNot value is already handled at ~SearchUIUtils.ts:5460, but statusNot falls through to the raw fallback and would render draft instead of Draft).

Investigation details, evidence & edge cases

Data flow: type -status:draft → parser produces a NOT_EQUAL_TO filter for status → buildFilterFormValuesFromQuery writes filtersForm.statusNot = ['draft'] → Save RHP (SearchSavePage.tsx:172) calls mapFiltersFormToLabelValueList → statusNot passes shouldShowFilter but line 5568 returns label = undefined → guard fails → filter dropped.

Why the query string itself is fine: buildSearchQueryString does preserve the negation (SearchQueryUtils.ts:548/554 emit ${isNegated ? '-' : ''}...), which is why search results are correct. The bug is isolated to the RHP's label/value display path.

Broader audit worth doing as part of the fix: any *Not form key that lacks a FILTER_VIEW_MAP entry will be dropped from the Save RHP the same way. NEGATABLE_FILTER_KEYS in SearchAdvancedFiltersForm.ts also lists WITHDRAWAL_STATUS_NOT, PAID_STATUS_NOT, etc. — verify each newly-negatable key has a matching FILTER_VIEW_MAP entry and getDisplayValue branch.

Confidence: High — verified directly against HEAD (9bf4fff): FILTER_VIEW_MAP contains zero Not keys, and mapFiltersFormToLabelValueList drops any key missing from it.

---

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

[JS00001]

closing as expected from this thread: https://expensify.slack.com/archives/C01GTK53T8Q/p1784034091555589