Expensify Card - Edit spend rule opens not here page for card admin when Rules are disabled

[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.7-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: #92740
Email or phone of affected tester (no customers): sojdnoijdionsojdod@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:

• User A invites User B to workspace as card admin.
• Workspace has at least one virtual card.
• Do not enable Rules.
• Perform steps below as card admin (User B).

1. Go to staging.new.expensify.com
2. Go to workspace settings > Expensify Card.
3. Open any card.
4. Click Edit spend rules.

Expected Result:

Edit spend rules should be disabled for card admin when Rules are disabled.

Actual Result:

Edit spend rules is not disabled for card admin when Rules are disabled.
Card admin can click on it which opens not here page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7179423_1781303942604.16.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @ShridharGoel

[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/861650ee69093df8812c35f4ab0a2599f4ea79883fbcb5c74c2019b33c81f56a

[melvin-bot]

@flodnv recently merged #92740, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @aldo-expensify (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

On the Expensify Card details page, the Edit spend rules menu item is shown to anyone with write access to the Expensify Card feature (which now includes the new Card Admin role). When the workspace's Rules feature is disabled, tapping it navigates to a spend-rules page that is gated behind the Rules feature, so the user lands on the "Not here" (NotFoundPage) screen instead of the option simply being hidden.

What is the root cause of that problem?

The entry point and the destination disagree on what they check:

• Entry point — the Edit spend rules menu item is gated only on canWriteExpensifyCard at WorkspaceExpensifyCardDetailsPage.tsx:388, where canWriteExpensifyCard = canMemberWrite(policy, currentUserLogin, EXPENSIFY_CARD) (line 119).
• Destination — navigateToSpendRules routes to RULES_SPEND_NEW/RULES_SPEND_EDIT (lines 190-197), which render SpendRulePageBase wrapped in AccessOrNotFoundWrapper with featureName={CONST.POLICY.MORE_FEATURES.ARE_RULES_ENABLED} (SpendRulePageBase.tsx:211-213).

canMemberWrite is a pure role-permission check — it only asks whether the role has WRITE access to the feature and never checks whether the feature is enabled on the policy (hasPolicyFeaturePermission, PolicyUtils.ts:183-195). So when Rules are disabled, canWriteExpensifyCard is still true, the button shows, and the wrapper on the target page falls through to the NotFoundPage.

Scope note (who is affected + relation to PR #92740)

#92740 introduced the Card Admin role, which is why the repro is written from a Card Admin's perspective. But the buggy gate (canWriteExpensifyCard with no Rules-enabled check) is not in that PR's diff — it pre-dates it. Because the gate depends only on Expensify Card write permission, this also reproduces for a Workspace Admin on a policy where Rules are disabled. The Card Admin work simply added a new role that reaches the same unguarded entry point.

Closely related: #92391 (a spend-rule entry point that also opens when Rules are disabled) — same class of "missing areRulesEnabled guard" bug.

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

Gate the Edit spend rules menu item on the Rules feature being enabled, in addition to write access. Add a feature-enabled check using the existing util:

const areRulesEnabled = isPolicyFeatureEnabled(policy, CONST.POLICY.MORE_FEATURES.ARE_RULES_ENABLED);

and change the condition at WorkspaceExpensifyCardDetailsPage.tsx:388 from {canWriteExpensifyCard && ( to {canWriteExpensifyCard && areRulesEnabled && (.

isPolicyFeatureEnabled(policy, ARE_RULES_ENABLED) resolves to policy?.areRulesEnabled (PolicyUtils.ts:1389), the same flag AccessOrNotFoundWrapper uses, so the entry point and destination stay consistent.

Also consider

The spend-rules summary row at WorkspaceExpensifyCardDetailsPage.tsx:349 is shown whenever a spend rule exists for the card. A rule can only exist if Rules were previously enabled, so this is lower risk, but worth confirming during implementation that a leftover summary row doesn't link into the gated pages.

What alternative solutions did you explore?

Removing the AccessOrNotFoundWrapper guard on the spend-rules pages — rejected, because the guard is correct; the entry point is what's wrong.

---

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

[ShridharGoel]

Handled in #93478