[Due for payment 2026-07-03] Rules - "Custom rules" section appears separately when rules are sorted by Card

[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.17-2
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: #93185
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.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:

• Paste Onyx.merge('betas', ['rulesRevamp']); in console.
• Invite another member to the workspace.
• Enable Expensify card and set it up with bank account.
• Enable Rules.
• Assign virtual card to yourself and workspace member.
• Create separate card spend rule for member's card and your card.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rules.
3. Go to Card restrictions.
4. Click Card table header.

Expected Result:

"Custom rules" section will not appear separately when rules are sorted by Card.

Actual Result:

"Custom rules" section appears separately when rules are sorted by Card.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188883_1782231196407.33.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @Krishna2323

[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/e9fa9aa834d3bc0517041d35e305f5521ba8de656b21f22b980e0320d48fa85b

[melvin-bot]

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

[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

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

In the revamped Rules → Card restrictions table, sorting by the Card column header makes the "Custom rules" section header render a second time (a spurious separate section). It should appear only once.

What is the root cause of that problem?

The section headers ("Default" / "Custom rules") are drawn by a boundary-detection scheme that assumes every row sharing the same isDefault value is contiguous. A header is emitted at row 0 and at every row whose isDefault differs from the previous row:

WorkspaceSpendRulesTableRow.tsx:55-57

But the sort comparator never sorts by isDefault — the card branch sorts purely on localeCompare(a.cardSummary, b.cardSummary):

WorkspaceSpendRulesTable/index.tsx:57-59

The single built-in default row has cardSummary = "All cards" (PolicyRulesPageRevamp.tsx:158, en.ts:7561). When sorted alphabetically, "All cards" lands in the middle of the custom card names (e.g. Alice → "All cards"(default) → Bob). That makes the isDefault sequence flip twice (false → true → false), so the "Custom rules" header renders both before and after the default row.

Why it's hidden by default and only shows when sorting

The data is built as [defaultSpendRule, ...customSpendRules] (PolicyRulesPageRevamp.tsx:179), so pre-sort there's exactly one boundary → one "Default" header then one "Custom rules" header. Sorting by cardSummary reorders the default row into the custom run and breaks that contiguity. The same latent defect applies to the Type column (index.tsx:47-55), which also doesn't pin isDefault.

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

Make isDefault the primary sort key at the top of compareItems so the default row always sorts to one end and the custom rows stay one contiguous run — guaranteeing exactly one "Custom rules" boundary. In WorkspaceSpendRulesTable/index.tsx:44, before the column-specific branches:

const compareItems: CompareItemsCallback<...> = (a, b, activeSorting) => {
    const orderMultiplier = activeSorting.order === 'asc' ? 1 : -1;

    // Keep the built-in default rule grouped so section headers stay contiguous
    if (a.isDefault !== b.isDefault) {
        return a.isDefault ? -1 : 1;
    }
    // ...existing 'type' / 'card' branches unchanged...
};

Returning a fixed value (not multiplied by orderMultiplier) pins the Default section to the top regardless of sort direction, matching the original layout. This single change also fixes the equivalent issue on the Type column.

What alternative solutions did you explore?

Partition the rows into default vs. custom groups structurally (outside the generic sort) instead of relying on the comparator. This is more robust but a larger change; the primary-sort-key fix is the minimal, lowest-risk option for a deploy blocker.

---

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

[blimpich]

behind beta