Cancel payment option is not shown for second admin after second admin pays the report

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

• Add business bank account to workspace.
• Invite User B as second admin.
• Invite User C as member.

1. Go to staging.new.expensify.com
2. [User C] Create an expense in workspace chat and click Submit.
3. [Owner] Approve User C's report.
4. [Owner] Go to workspace settings > Workflows.
5. [Owner] Disable and reenable Workflows.
6. [User B] Open the report > click Pay > Mark as paid.
7. [User B] Click More.

Expected Result:

Cancel payment option will be shown for second admin after second admin pays the report.

Actual Result:

Cancel payment option is not shown for second admin after second admin pays the report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7250494_1788464480101.6.mp4

View all open jobs on GitHub

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

[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/15ee809b7745f8fda52e79792e99402ce0e7be1c743edca0ff487deb345d167c

[melvin-bot]

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

[melvin-bot]

@chuckdries @ikevin127 you have been assigned to this deploy blocker because you reviewed the offending PR: #95925

[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: #95925 - "Allow any workspace admin to pay reports" by @lorretheboy (High confidence)
Related Issues: #100332 (StagingDeployCash 9.4.70-0), #98082 (already in production — added the Cancel payment gate that #95925 left behind)

Recommendation: ROLL FORWARD

#95925 widened the pay gate to a new shared helper (canAdminPayReport) at three call sites but left the cancel payment gate on the old, narrower inline condition, so a second admin can now pay a report they can no longer cancel. Reverting a 24‑file payments PR is far riskier than the one‑line fix below, so roll forward.

Suggested fix in src/libs/ReportSecondaryActionUtils.ts (replace lines 481‑484):

// Mirror the pay gate (canIOUBePaid.canPay): whoever could mark the report paid can cancel it, no admin requirement.
const canCancelPayment = isPayer || canAdminPayReport(policy, currentUserEmail);

…importing canAdminPayReport from ./PolicyUtils (the now-unused canMemberWrite import is still used elsewhere in the file, so it stays).

Assigned: @lorretheboy (PR author), @chuckdries and @ikevin127 (approving reviewers) from the highest-confidence causing PR only
Labels: No label changes. DeployBlockerCash is kept (App-side fix required); DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• Reported on 9.4.70-0, staging only, "N/A - new feature, doesn't exist in prod". That matches Allow any workspace admin to pay reports #95925 exactly: it is the PR that first lets a non-payer workspace admin pay a report on a policy with direct (bank) reimbursement. Before it, User B would never have seen the Pay button in step 6, so the bug could not exist in production.
• Allow any workspace admin to pay reports #95925 introduced canAdminPayReport in PolicyUtils.ts and swapped three pay gates over to it:
  • ReportPreviewActionUtils.canPay L141
  • ReportPrimaryActionUtils.isPrimaryPayAction L233
  • ReportWorkflow.canIOUBePaid L246
• The old inline condition it replaced was isReportPayer || (isGroupPolicy(policy) && policy?.reimbursementChoice === REIMBURSEMENT_MANUAL && canMemberWrite(policy, currentUserLogin, WORKFLOWS_PAYMENTS)) — i.e. a non-payer admin could only pay under manual reimbursement.
• A fourth copy of that same condition lives in the Cancel payment gate and was not updated. It is now the only remaining occurrence in src/:

  $ grep -rn "REIMBURSEMENT_MANUAL && canMemberWrite" src/
  src/libs/ReportSecondaryActionUtils.ts:484
  

Verification

Affected file: src/libs/ReportSecondaryActionUtils.ts L481‑L488 inside isCancelPaymentAction, which feeds CONST.REPORT.SECONDARY_ACTIONS.CANCEL_PAYMENT in getSecondaryReportActions L1094‑L1096 — the More menu from step 7.

Note that #95925 does not list ReportSecondaryActionUtils.ts in its changed files, and that is precisely the defect: it changed the semantics that this file's gate explicitly claims to mirror ("Mirror the pay gate (canIOUBePaid.canPay): whoever could mark the report paid can cancel it") without touching the mirror. The mirror itself was correct when #98082 wrote it on 2026-09-01 (already in production, not in this checklist); #95925 merged 2026-09-03T18:13Z and broke the invariant.

No other PR in the 9.4.70 checklist touches payment/cancel-payment gating, and ReportSecondaryActionUtils.ts has had no commits since #98082.

Root Cause

With a business bank account on the workspace, policy.reimbursementChoice is REIMBURSEMENT_YES (direct reimbursement). Steps 4‑5 (disable and re-enable Workflows) are what force the policy back into the REIMBURSEMENT_YES + designated-reimburser (owner) shape; with no designated reimburser, isPayer short-circuits to isAdmin and the bug would not show.

For User B (second admin, not the reimburser, not a sharee on the business bank account):

• ReportUtils.isPayer → under REIMBURSEMENT_YES it returns isReimburser || (isAdmin && hasAccessToBankAccount) → false.
• canAdminPayReport(policy, userB) → REIMBURSEMENT_YES is a configured choice and User B has WORKFLOWS_PAYMENTS write → true → Pay is shown (step 6 succeeds, report becomes APPROVED/REIMBURSED with a PAY action of type ELSEWHERE).
• isCancelPaymentAction → canCancelPayment = isPayer /* false */ || (reimbursementChoice === REIMBURSEMENT_MANUAL /* false, it is YES */ && …) → false, so it returns early at L486‑L488 and CANCEL_PAYMENT is never pushed — even though the report is in the exact APPROVED + REIMBURSED + paid-elsewhere state the function is designed to allow cancelling.

So the user is left in a state they can enter but not exit: a payment they made themselves that they cannot cancel.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards change so the AI reviewer catches the next one. Proposed for Expensify/App — an amendment to the existing CONSISTENCY-3 (Eliminate code duplication) rather than a new rule, since it is the "partial extraction" variant of duplication that CONSISTENCY-3 does not currently flag:

• Rule: CONSISTENCY-3 (amendment) — Finish the extraction: when a PR replaces an inline predicate with a new shared helper, every copy must be migrated
• Condition: Flag a diff that introduces a new exported helper in a *Utils.ts file and replaces an inline boolean expression with it at some call sites, when identical or near-identical copies of that expression still exist elsewhere in src/. Migrate them all in the same PR, or state in the PR why a remaining copy must keep the old semantics.
• Why: The un-migrated copies silently drift from the new semantics. Here, three pay gates were widened to canAdminPayReport while the fourth copy — the Cancel payment gate, whose own comment says it mirrors the pay gate — kept the old manual-only condition, letting a second admin pay a report they then could not cancel (this deploy blocker).
• Search pattern: for each expression removed by the diff, grep src/ for a distinctive fragment of it (here grep -rn "REIMBURSEMENT_MANUAL && canMemberWrite" src/), and treat any surviving hit outside the diff as a finding. A comment near a surviving hit that names the extracted concept ("mirror", "same as", "keep in sync with") raises the confidence.
• Offending code (❌):

  App/src/libs/ReportSecondaryActionUtils.ts

  Lines 481 to 484 in f29a3da

  	// Mirror the pay gate (canIOUBePaid.canPay): whoever could mark the report paid can cancel it, no admin requirement.
  	const canCancelPayment =
  	isPayer ||
  	(policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL && canMemberWrite(policy, currentUserEmail, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS));

• Fix (✅): the migrated call sites in the same PR, e.g.

  App/src/libs/ReportPreviewActionUtils.ts

  Line 141 in f29a3da

  const canPayReport = isReportPayer || canAdminPayReport(policy, currentUserLogin);

  and

  App/src/libs/ReportPrimaryActionUtils.ts

  Line 233 in f29a3da

  const canPayReport = isReportPayer || (!!canNonPayerAdminPay && canAdminPayReport(policy, currentUserLogin));

If it's worth adding, a maintainer can open it in Expensify/App as a draft PR against .claude/skills/coding-standards/.

---

view run