[Due for payment 2026-08-07] "You can't remove.." modal is not shown when people admin removes member with Expensify Card

[applause-bot]

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

---

Version Number: 9.4.46-5
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: #96267
Email or phone of affected tester (no customers): sdjisndoisnjodjsi@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:

• Create a Control workspace.
• Assign a virtual card to any member in the workspace.
• Owner invites User B as people admin to the workspace.

1. Go to staging.new.expensify.com
2. [Owner] Go to workspace settings > Members.
3. [Owner] Click on the member that has Expensify Card.
4. [Owner] Click Remove from workspace.
   → "You can't remove.." modal is shown.
5. [User B] Go to workspace settings > Members (do not go to Workflows).
6. [User B] Click on the member that has Expensify Card.
7. [User B] Click Remove from workspace.

Expected Result:

"You can't remove.." modal will be shown.

Actual Result:

"You can't remove.." modal is not shown when people admin removes member with Expensify Card.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7222123_1785432210880.20.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7222123

Issue Owner

Current Issue Owner: @eVoloshchak

[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/0d42974df6b1b9676409c14019c6ddd6b73cb2ea685a0548be78af19e53cb087

[melvin-bot]

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

[melvin-bot]

@deetergp @eVoloshchak you have been assigned to this deploy blocker because you reviewed the offending PR: #96267

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96267 - "fix: block removing a workspace member who holds an active Expensify Card" by @yusufdeveloper2903 (High confidence)
Related Issues: #94622 (the issue this PR was fixing)

Recommendation: REVERT

The client-side guard added by #96267 reads Expensify Card data that is not loaded on the Members flow for a non-owner people admin, so the blocking modal silently fails to appear. The PR is self-contained and cleanly revertible; a targeted roll-forward fix is also viable (see below).

Assigned: @yusufdeveloper2903 (PR author), @deetergp & @eVoloshchak (approving reviewers) from the causing PR.
Labels: No change. DeployBlockerCash is correct for a frontend bug and is kept; no DeployBlocker was present.

📋 Detailed Analysis

Evidence

• The bug is a brand-new behavior that only exists on staging (the "You can't remove…" Expensify Card guard does not exist in production), and fix: block removing a workspace member who holds an active Expensify … #96267 is the PR that introduced exactly that guard. Merged 2026-07-27, reported on 9.4.46-5 (2026-07-30) — timeline aligns.
• The PR itself states the guard is "derived entirely from Onyx data that is already local." That is precisely the failure: the data is only local when it has already been fetched, which is not guaranteed on the Members flow.
• The repro explicitly instructs User B to open Members "(do not go to Workflows)" — opening Workflows / the Expensify Card page is what triggers the workspace card data fetch into Onyx. Without that, the guard has no card data to evaluate. The owner passes because their session already has the workspace Expensify Card feed/settings loaded.

Verification

Affected files (all modified by #96267):

• src/libs/CardUtils.ts — new hasActiveExpensifyCardAssigned(workspaceCards, accountID) helper.
• src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx — single-member removal guard.
• src/pages/workspace/WorkspaceMembersPage.tsx — bulk removal guard.

Confirmed the guard consumes lazily-fetched Onyx data:

• workspaceAccountID = policy?.policyAccountID ?? CONST.DEFAULT_NUMBER_ID — WorkspaceMemberDetailsPage.tsx#L115
• workspaceCards is built from cardList (WORKSPACE_CARDS_LIST), cardFeeds, and expensifyCardSettings: WorkspaceMemberDetailsPage.tsx#L126-L152
• The removal decision reads hasActiveExpensifyCard: WorkspaceMemberDetailsPage.tsx#L158 and gates the modal at L192 / L285.
• The only fetch this page triggers is openPolicyMemberProfilePage(policyID, accountID) — WorkspaceMemberDetailsPage.tsx#L170 — which does not load the workspace Expensify Card list. Nothing on the Members flow calls the Expensify Card page fetch, so for an admin who lands directly on Members, WORKSPACE_CARDS_LIST / cardFeeds / expensifyCardSettings are empty.
• The helper returns false for an undefined/empty card list (hasAssignedCardMatching over an empty list): CardUtils.ts hasActiveExpensifyCardAssigned — its own unit test asserts hasActiveExpensifyCardAssigned(undefined, id) === false.

Root Cause

hasActiveExpensifyCardAssigned is computed against getAllCardsForWorkspace(workspaceAccountID, cardList, cardFeeds, expensifyCardSettings), whose inputs come from Onyx keys that are only hydrated once a card-loading surface (the Expensify Card page or Workflows) has been opened in the current session. The owner typically already has this data hydrated, so the guard evaluates correctly and the "You can't remove…" modal appears. A non-owner people admin who navigates straight to Members > member > Remove has an empty card list, so hasActiveExpensifyCard evaluates to false, the guard is skipped, and removal proceeds without the modal — the exact reported symptom. The check silently depends on data availability rather than on a definitive answer to "does this member hold an active Expensify Card."

This is purely a client-side data-availability defect in the App PR, so it is a Frontend bug. The fix belongs in Expensify/App (either revert the guard, or make the guard's data reliably available). This is not cosmetic — the guard exists to prevent removal that causes the backend to re-home the member's unreported Expensify Card transactions — so DEMOTE is not appropriate.

Recommended resolutions

• Primary — REVERT fix: block removing a workspace member who holds an active Expensify … #96267: it is self-contained (CardUtils helper + two pages + en.ts copy + tests) and reverting only returns to current production behavior, which does not regress prod.
• Alternative — ROLL FORWARD: ensure the workspace Expensify Card data is fetched on the Members / WorkspaceMemberDetails pages (e.g. trigger the Expensify Card list fetch there, analogous to opening the Expensify Card page) so the guard has the card data regardless of who is viewing and whether Workflows/Card pages were visited first. Optionally, gate on "cards loaded" state to avoid making a removal decision before the data resolves.