Workflows - Payments admin cannot change payer back to payment admin

[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.29-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: #94018
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@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.
• Invite user as payments admin to the workspace.
• Perform the steps below as payments admin:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Workflows.
3. Click Add bank account.
4. Click Log into your bank.
5. Complete add bank account flow.
6. Click Payer.
7. Change it to owner and save it.
8. Click Payer.
9. Change it to payments admin and save it.

Expected Result:

Payments admin can change payer back to payments admin because the bank account is added by payments admin.

Actual Result:

Payments admin can change payer back to payments admin when the bank account is added by payments admin.
It shows error "Payments admin doesn't have access to this bank account",

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

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

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/061e0b352252b27384a8389993f8b07c35d781aeb5a77a7c4d888260f6fd93cb

[melvin-bot]

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

[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

A Payments Admin who set up the workspace bank account changes the payer to the Owner, then tries to change it back to themselves and hits the error "Payments admin doesn't have access to this bank account", even though they added the account. Deploy blocker from #94018 (adds Payments Admin workspace access).

Root Cause

The "can the current user share this bank account?" gate in handleShareBankAccount only treats the workspace owner as inherently authorized; everyone else must already be in accountData.sharees. A Payments Admin is neither the workspace owner nor reliably present in sharees, so the check falls through to the error modal.

WorkspaceWorkflowsPayerPage.tsx:238-246:

const isOwner = policy?.owner === currentUserPersonalDetails?.login;
// Current user has no right to share (not owner and not a sharee) — show error
if (!isOwner && !isAccountAlreadyShared && !isAccountAlreadySharedWithCurrentUser) {
    setShowErrorModal(true);
    return;
}

PR #94018 newly allows Payments Admins to be payers and manage Workflows > Payments, but this authorization gate was never updated to recognize them — so it still assumes only the Owner can (re)share the account.

Solution

Broaden the gate so a member with WORKFLOWS_PAYMENTS write access (i.e. a Payments Admin) is also allowed to share, using the canMemberWrite helper already used for payer eligibility elsewhere in this same file (lines 118 and 275):

const canCurrentUserManagePayments = canMemberWrite(policy, currentUserPersonalDetails?.login ?? '', CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS);
if (!isOwner && !canCurrentUserManagePayments && !isAccountAlreadyShared && !isAccountAlreadySharedWithCurrentUser) {
    setShowErrorModal(true);
    return;
}

This lets the Payments Admin proceed to the normal share/confirm flow instead of being blocked, matching the expected behavior in the report.

Investigation details & caveats

• Error string: en.ts:2875 (errorDescription).
• Only reproduces on the auto-reimbursement + bank-account path (handleShareBankAccount → error modal). Manual reimbursement / no-bank-account paths go through onButtonPress and are unaffected.
• Data-model note: There is no field on the bank account (AccountData / ACHAccount) recording its creator — sharees (emails) is the only client-side access marker, and it's populated server-side. So the frontend cannot detect "I created this account" directly; keying off WORKFLOWS_PAYMENTS write access is the cleanest client-side signal that the user is authorized to manage payments for this policy.
• Confirm before merging: this fix assumes the backend actually lets a Payments Admin share/set the payer (i.e. the SHARE_BANK_ACCOUNT_AND_UPDATE_POLICY_REIMBURSER command succeeds for them). If the backend also rejects them, a matching backend change (Auth/Web-Expensify) would be required in addition to this frontend fix. Given the feature intent in Add payments admin workspace access #94018, the frontend gate is the most likely culprit.
• Since this is a deploy blocker, reverting Add payments admin workspace access #94018 is also a valid resolution if a fix can't be verified quickly.

Likely-related deploy blockers from the same PR (Payments Admin feature): #95561, #95537, #95560, #95615.

---

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