Domains - Member who requested admin access remains in Requests list after closing account

[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.77-1
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: #100161
Email or phone of affected tester (no customers): applausetester+sdodjsoddddds@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:

• As Expensifail domain member, go to Workspaces > Domains > applause.expensifail.com > Request admin access.
• Log in as Expensifal domain admin and perform the steps below:

1. Go to staging.new.expensify.com
2. Go to Workspaces > Domains.
3. Click applause.expensifail.com
4. Go to Domains members.
5. Search for the member who requested admin access.
6. Click on the member > Close account > Force close account > Close account.
7. Go to Domain admins.

Expected Result:

The member whose account is closed will no longer appear in Requests list.

Actual Result:

The member whose account is closed still remains in Requests list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7258789_1789315892940.3.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @rayane-d

[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/77c9abfed5ec8e0e6c8b2db6cd11c8d6291987a23a316a79163330063b564432

[melvin-bot]

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

[melvin-bot]

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

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

[melvin-bot]

@mountiny @ZhenjaHorbach you have been assigned to this deploy blocker because you reviewed the offending PR: #100161

[melvin-bot]

@jakubstec you have been assigned to this deploy blocker because you authored the offending PR: #100161