[Due for payment 2026-02-27] [$250] Approvers Lose Ability to Reject Expenses When Acting as Vacation Delegates or After Being Removed From Approval Workflow

[m-natarajan]

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.3.1-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @garrettmknight
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

Scenario 1: Approver Removed From Workflow
Preconditions:
Approvals enabled
Submissiomn set to Manual
Initial approval workflow: Submitter A → Approver A

1. Submitter A creates a report with multiple expenses
2. Submitter A submits the report to Approver A
3. Admin updates the approval workflow and changes the approver to Approver B
4. Approver A accesses the report

Scenario 2: Vacation Delegate Flow

1. Submitter A creates a report with multiple expenses
2. Submitter A submits the report to Approver A
3. Approver B is set as Approver A’s vacation delegate
4. Vacation delegation routes the report to Approver B
5. Approver B opens the report

Expected Result:

The user reviewing the report (original approver or vacation delegate) should be able to:
Reject individual expenses
See the Reject option in:
Bulk select menu
Individual expense “More” menu

Actual Result:

The Reject option is missing:
Not available in bulk select
Not available in individual expense menus

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.2210.mp4

Recording.2211.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022011976783879502778
• Upwork Job ID: 2011976783879502778
• Last Price Increase: 2026-01-30

Issue Owner

Current Issue Owner: @NicMendonca

[melvin-bot]

Triggered auto assignment to @NicMendonca (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Approvers can't reject expenses when:

1. They're acting as a vacation delegate
2. They were the original approver but got removed from the workflow

The Reject option is missing from both bulk select and individual expense menus.

What is the root cause of that problem?

In src/libs/ReportUtils.ts, canRejectReportAction checks:

const isCurrentUserManager = report?.managerID === currentUserAccountID;
const userCanReject = isReportApprover && isCurrentUserManager;

For vacation delegates, managerID stays as the original approver (who's on vacation), not the delegate. So the delegate fails the managerID check even though they legitimately have the report for review.

The SUBMITTED report action actually has the delegate info:

• vacationer: login of the original approver on vacation
• to: login of the vacation delegate

But this isn't being checked.

What changes do you think we should make in order to solve the problem?

1. Add optional reportActions param to canRejectReportAction

2. Add helper to check vacation delegate status:

function isVacationDelegateForReport(reportActions: OnyxEntry<ReportActions>, currentUserLogin: string): boolean {
    const submittedAction = Object.values(reportActions ?? {}).find(
        action => action.actionName === CONST.REPORT.ACTIONS.TYPE.SUBMITTED
    );
    if (!submittedAction?.originalMessage?.vacationer) {
        return false;
    }
    return submittedAction.originalMessage.to === currentUserLogin;
}

3. Update the permission check:

-const userCanReject = isReportApprover && isCurrentUserManager;
+const isVacationDelegate = isVacationDelegateForReport(reportActions, currentUserLogin);
+const userCanReject = isReportApprover && (isCurrentUserManager || isVacationDelegate);

4. Update call sites to pass reportActions:

• src/libs/ReportSecondaryActionUtils.ts
• src/hooks/useSelectedTransactionsActions.ts
• src/components/Search/index.tsx

What alternative solutions did you explore? (Optional)

Could update managerID when delegation happens, but that would require backend changes and might break other logic that expects managerID to be the actual manager.

[melvin-bot]

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

[melvin-bot]

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

[annaweber830]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Approvers lose the ability to reject expenses in two cases:

• When they’re acting as a vacation delegate for the approver.
• When they were the original approver, but were later removed from the approval workflow after the report was submitted.
  In both cases, the Reject option is missing from:
• The bulk select actions
• The individual expense “More” menu

What is the root cause of that problem?

canRejectReportAction() in ReportUtils.ts is overly restrictive: it requires the user to be both:
the current report approver/manager (report.managerID === currentUserAccountID), and
an approver in the policy workflow (isApproverUtils(policy, currentUserLogin))
In the problematic scenarios, the user can still be the active reviewer of the report, but they fail the policy approver check (because they are a delegate, or they were removed from the workflow after submission). That causes Reject to be hidden everywhere it’s gated by canRejectReportAction().

What changes do you think we should make in order to solve the problem?

• Update canRejectReportAction() to treat Reject as an approval action and gate it by whether the user is the current report manager/approver (and approvals are enabled), rather than also requiring the user to be an “approver” in the policy workflow list.
• Keep existing constraints (e.g., only allow on processing reports; exclude IOU and invoice reports) unchanged.
  

  App/src/libs/ReportUtils.ts

  Lines 12597 to 12607 in e94f05d

  	const isReportApprover = isApproverUtils(policy, currentUserLogin);
  	const isReportBeingProcessed = isProcessingReport(report);
  	const isIOU = isIOUReport(report);
  	const isInvoice = isInvoiceReport(report);
  	const isCurrentUserManager = report?.managerID === currentUserAccountID;
  	const userCanReject = isReportApprover && isCurrentUserManager;
  	if (!userCanReject) {
  	return false; // must be approver or payer
  	}

const isReportBeingProcessed = isProcessingReport(report);
    const isIOU = isIOUReport(report);
    const isInvoice = isInvoiceReport(report);
    const currentUserAccountID = getCurrentUserAccountID();
    const isCurrentUserManager = report?.managerID === currentUserAccountID;
    const isApprovalEnabled = !!policy?.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;

    if (!isCurrentUserManager || !isApprovalEnabled) {
        return false;
    }

What alternative solutions did you explore? (Optional)

[mkhutornyi]

Based on #72465 (comment), only the report's manager can reject expenses.
But @garrettmknight expects that other approvers (set in approval workflow) should see reject option as well.
@trjExpensify can you please confirm?

[trjExpensify]

Scenario 1: Approver Removed From Workflow
Preconditions:
Approvals enabled
Submissiomn set to Manual
Initial approval workflow: Submitter A → Approver A

1. Submitter A creates a report with multiple expenses
2. Submitter A submits the report to Approver A
3. Admin updates the approval workflow and changes the approver to Approver B
4. Approver A accesses the report

I think what @garrettmknight is saying here is that the admin has updated the approval workflow in the workspace settings, they haven't gone to the report and used "Change approver" to take control and route it to a different approver. If so, the report's manager would still be Approver A at this point, and thus they should be able to take actions like rejecting the expenses on said report.