[Due for payment 2026-09-25] Change approver - No error message when remove approver

[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: v9.4.54-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/53697091/test-cases/87848130
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Ventura / Chrome
App Component: Other

Action Performed:

Preconditions:

1. User is an Admin of a Control Workspace
2. At least one other member is added to the Workspace
3. Workflow / Approvals are enabled for the workspace

STR:

1. Navigate to the Workspace chat
2. Create a manual expense and submit
3. Open the newly created expense report
4. Navigate to report details
5. Click More > Change approver
6. Select the workspace member as approver
7. Navigate to Workspace Settings > [Workspace Name] > Members
8. Select the checkbox next to the member who was just assigned as the approver
9. Click the 1 selected dropdown > Click "Remove member"
10. Click "Remove" on the modal

Expected Result:

An error message is displayed: "xxx has outstanding expense reports to approve. Please ask them to approve, or take control of their reports before removing them from the workspace"

Actual Result:

No error message. Member just deleted from the list

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7235438_1786958184275.REC-20260817121424.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022089311619201881742
• Upwork Job ID: 2089311619201881742
• Last Price Increase: 2026-08-17

Issue Owner

Current Issue Owner: @rojiphil

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

[MelvinBot]

Proposal

Problem

Removing a workspace member who is the approver of an outstanding expense report succeeds silently. The expected blocking error — "…has outstanding expense reports to approve. Please ask them to approve, or take control of their reports before removing them from the workspace." — is never shown.

I reproduced this end-to-end on web (Control workspace, Approvals enabled): after setting a member as a report's approver via Change approver, removing them from Members showed only the generic "Are you sure you want to remove …?" modal and removed them immediately. The report silently reverted to the workspace owner for approval instead of blocking removal. Evidence screenshots are attached above.

Root Cause

The member-removal flows decide whether a member is an "approver" solely from isPolicyApprover(), which inspects only the workspace approval-workflow config (policy.approver and employeeList submitsTo/forwardsTo/overLimitForwardsTo).

The Change approver action (addReportApprover) is report-scoped — it writes the report's managerID, a report action, and nextStep, but never touches the policy config. So a member who is only an ad-hoc report approver is invisible to isPolicyApprover(), and neither removal flow ever checks for reports the member still has to approve.

Additionally, the language string the reporter expected — workspace.people.removeMemberPromptPendingApproval at en.ts:6810 — is dead copy: it exists but has no reference anywhere in code (same for cannotRemoveUserDueToReport). The "pending approval" guard was never wired up.

Investigation details & evidence

Bulk flow (STR path — Members list → "1 selected" → Remove member):

• WorkspaceMembersPage.tsx:164-190 — the confirm prompt only branches on isPolicyApprover / exporter, else falls through to the generic removeMembersPrompt. No outstanding-report check.
• WorkspaceMembersPage.tsx:230-266 — on confirm, removeMembers() is called unconditionally; there is no gate that can block removal.

Single-member flow (WorkspaceMemberDetailsPage.tsx:181-201) — richer branching (removeMemberPromptApprover, reimburser, exporter, techContact) but still gated on the same isPolicyApprover config check and has no "outstanding reports to approve" branch either.

Note on getOutstandingReportsForUser / OUTSTANDING_REPORTS_BY_POLICY_ID: that existing derived value keys reports by owner/submitter (ownerAccountID), so it answers "reports a member submitted", not "reports a member must approve". The needed signal is different — reports where managerID === accountID (or the ad-hoc approver) that are awaiting that member's approval.

Alternatives considered: A server-side error on the removal command is possible, but the interpolated (memberName) => … string living in App's en.ts indicates this warning was intended to be rendered client-side. isPolicyApprover returning false here is correct for its own purpose (workflow config) — the bug is the missing pending-approval check, not a bug in isPolicyApprover.

Suggested Fix

Add a "does this member still have reports to approve?" check to both removal flows and surface removeMemberPromptPendingApproval (as a blocking error, matching the expected behavior) when it's true:

1. Add a helper (e.g. in ReportUtils/PolicyUtils) that returns reports on the policy whose managerID equals the member's accountID and that are in a state awaiting approval (open/submitted, not settled/closed) — covering ad-hoc Change approver assignments, not just workflow config.
2. In WorkspaceMembersPage.tsx and WorkspaceMemberDetailsPage.tsx, when the member(s) to remove have such reports, show removeMemberPromptPendingApproval and block the removal (disable/short-circuit the Remove action) instead of proceeding.

Confidence: High — code path and web reproduction agree.

---

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022089311619201881742

[Uzaifm127]

@aimane-chnaif

I reviewed the Melvin proposal and found:

1. This line in Melvin proposal's root cause is incorrect:

   The member-removal flows decide whether a member is an "approver" solely from isPolicyApprover()

2. A real regression in its proposal:

Melvin-regression.mp4

---

I believe a better proposal than Melvin is possible and I have a better one.

[melvin-bot]

@aimane-chnaif Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[Uzaifm127]

@mallenexpensify We aren't getting any response from @aimane-chnaif on this issue (maybe they aren't available).

I left a comment pointing out the issues in Melvin proposal in this comment.

Could you please help us to move this issue further as per this Slack thread, thanks.