Expense - Approve and Reject options are not available for Admin after changing workspace

[jponikarchuk]

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.9-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/27754595/test-cases/77992811
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 15.7.3 Chrome, iPhone 15 iOS 26.1
App Component: Money Requests

Action Performed:

Preconditions: Create an Admin and a Member, selecting "Manage my team's expenses" option

1. As Admin, invite the Member to the workspace
2. As Member, create 2 expenses in your own workspace chat, click Submit
3. As Member, open the report, click More - Change workspace - Admin's workspace
4. As Admin, navigate to the Member's workspace chat, open the expense report - there is no Approve option
5. As Admin, select one of the expenses - More menu - there is no Reject option
6. As a Member, open the workspace report - there is an Approve option, but the system message says "Waiting for Admin to approve expenses"

Expected Result:

Approve option is displayed in the expense report for the workspace Admin after submitter changed the workspace. Reject option is available in the expense details/ More menu

Actual Result:

For Admin: Approve button and option are not displayed, system message says "Waiting for Member to approve expenses". Reject option is not available in the expense details
For Member: Approve button is displayed, but system message says "Waiting for Admin to approve expenses".

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @cead22

[melvin-bot]

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

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

[annaweber830]

Proposal

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

When a member submits expenses and then changes the report’s workspace to an admin’s workspace, the approval ownership becomes incorrect: the workspace admin can no longer see Approve/Reject, while the member can. This blocks the intended workflow where the admin should be able to approve/reject the submitted expenses in their workspace.

What is the root cause of that problem?

During “Change workspace”, we optimistically update policyID but we don’t update managerID to the destination policy’s approver unless the existing managerID is not a member of the new policy. If the submitter is invited to the admin’s workspace (so they are a member), the report keeps managerID pointing to the submitter, effectively making them the “manager/approver” in NewDot.

The changeReportPolicy flow calls buildOptimisticChangePolicyData(), where managerID is only reassigned when the current manager is not a member of the destination policy:

App/src/libs/actions/Report.ts

Lines 5850 to 5875 in 87e6d66

	// We reopen and reassign the report if the report is open/submitted and the manager is not a member of the new policy. This is to prevent the old manager from seeing a report that they can't action on.
	let newStatusNum = report?.statusNum;
	const isOpenOrSubmitted = isOpenExpenseReport(report) || isProcessingReport(report);
	const managerLogin = PersonalDetailsUtils.getLoginByAccountID(report.managerID ?? CONST.DEFAULT_NUMBER_ID);
	if (isOpenOrSubmitted && managerLogin && !isPolicyMember(policy, managerLogin)) {
	newStatusNum = CONST.REPORT.STATUS_NUM.OPEN;
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: CONST.REPORT.STATE_NUM.OPEN,
	statusNum: CONST.REPORT.STATUS_NUM.OPEN,
	managerID: getNextApproverAccountID(report, true),
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: report.stateNum,
	statusNum: report.statusNum,
	managerID: report.managerID,
	},
	});
	}

But the visibility of Approve and Reject is gated on report.managerID === currentUserAccountID, so the workspace admin won’t see these actions if managerID remains set to the submitter:

App/src/libs/actions/IOU/index.ts

Lines 9382 to 9409 in 87e6d66

	function canApproveIOU(iouReport: OnyxTypes.OnyxInputOrEntry<OnyxTypes.Report>, policy: OnyxTypes.OnyxInputOrEntry<OnyxTypes.Policy>, iouTransactions?: OnyxTypes.Transaction[]) {
	// Only expense reports can be approved
	if (!isExpenseReport(iouReport) || !(policy && isPaidGroupPolicy(policy))) {
	return false;
	}
	const isOnSubmitAndClosePolicy = isSubmitAndClose(policy);
	if (isOnSubmitAndClosePolicy) {
	return false;
	}
	const managerID = iouReport?.managerID ?? CONST.DEFAULT_NUMBER_ID;
	const isCurrentUserManager = managerID === userAccountID;
	const isOpenExpenseReport = isOpenExpenseReportReportUtils(iouReport);
	const isApproved = isReportApproved({report: iouReport});
	const iouSettled = isSettled(iouReport);
	const reportNameValuePairs = allReportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${iouReport?.reportID}`];
	const isArchivedExpenseReport = isArchivedReport(reportNameValuePairs);
	const reportTransactions = iouTransactions ?? getReportTransactions(iouReport?.reportID);
	const hasOnlyPendingCardOrScanningTransactions = reportTransactions.length > 0 && reportTransactions.every((transaction) => isScanning(transaction) || isPending(transaction));
	if (hasOnlyPendingCardOrScanningTransactions) {
	return false;
	}
	const isPayAtEndExpenseReport = isPayAtEndExpenseReportReportUtils(iouReport ?? undefined, reportTransactions);
	const isClosedReport = isClosedReportUtil(iouReport);
	return (
	reportTransactions.length > 0 && isCurrentUserManager && !isOpenExpenseReport && !isApproved && !iouSettled && !isArchivedExpenseReport && !isPayAtEndExpenseReport && !isClosedReport
	);

App/src/libs/ReportUtils.ts

Lines 12629 to 12655 in 87e6d66

	function canRejectReportAction(currentUserLogin: string, report: Report, policy?: Policy): boolean {
	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
	}
	if (isIOU) {
	return false; // Disable IOU
	}
	if (isInvoice) {
	return false; // Disable invoice
	}
	if (isReportBeingProcessed) {
	return true; // non-IOU reports can be rejected while processing
	}
	return false;
	}

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

When changing the workspace (policy) of an expense report that is already submitted/processing, we should recompute the report’s managerID using the destination policy’s approval routing (approval chain / submit-to), and update the optimistic nextStep using that updated managerID. That ensures the report is owned by the correct approver in the new workspace, and the admin sees Approve/Reject immediately.

The fix should be implemented in buildOptimisticChangePolicyData():

App/src/libs/actions/Report.ts

Lines 5811 to 5965 in 87e6d66

	function buildOptimisticChangePolicyData(
	report: Report,
	policy: Policy,
	currentUserAccountID: number,
	email: string,
	hasViolationsParam: boolean,
	isASAPSubmitBetaEnabled: boolean,
	isReportLastVisibleArchived: boolean | undefined,
	reportNextStep?: ReportNextStepDeprecated,
	optimisticPolicyExpenseChatReport?: Report,
	) {
	const optimisticData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.SNAPSHOT
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS
	| typeof ONYXKEYS.COLLECTION.NEXT_STEP
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	>
	> = [];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION>> = [];
	const failureData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.NEXT_STEP
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	>
	> = [];
	// 1. Optimistically set the policyID on the report (and all its threads) by:
	// 1.1 Preprocess reports to create a map of parentReportID to child reports list of reportIDs
	// 1.2 Recursively update the policyID of the report and all its child reports
	const reportID = report.reportID;
	const reportIDToThreadsReportIDsMap = buildReportIDToThreadsReportIDsMap();
	updatePolicyIdForReportAndThreads(reportID, policy.id, reportIDToThreadsReportIDsMap, optimisticData, failureData);
	// We reopen and reassign the report if the report is open/submitted and the manager is not a member of the new policy. This is to prevent the old manager from seeing a report that they can't action on.
	let newStatusNum = report?.statusNum;
	const isOpenOrSubmitted = isOpenExpenseReport(report) || isProcessingReport(report);
	const managerLogin = PersonalDetailsUtils.getLoginByAccountID(report.managerID ?? CONST.DEFAULT_NUMBER_ID);
	if (isOpenOrSubmitted && managerLogin && !isPolicyMember(policy, managerLogin)) {
	newStatusNum = CONST.REPORT.STATUS_NUM.OPEN;
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: CONST.REPORT.STATE_NUM.OPEN,
	statusNum: CONST.REPORT.STATUS_NUM.OPEN,
	managerID: getNextApproverAccountID(report, true),
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: report.stateNum,
	statusNum: report.statusNum,
	managerID: report.managerID,
	},
	});
	}
	const isInstantSubmitEnabledLocal = isInstantSubmitEnabled(policy);
	const isSubmitAndCloseLocal = isSubmitAndClose(policy);
	const arePaymentsDisabled = policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO;
	if (isProcessingReport(report) && isInstantSubmitEnabledLocal && isSubmitAndCloseLocal && arePaymentsDisabled) {
	newStatusNum = CONST.REPORT.STATUS_NUM.CLOSED;
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	stateNum: report.stateNum,
	statusNum: report.statusNum,
	},
	});
	}
	if (newStatusNum != null && newStatusNum !== undefined) {
	// buildOptimisticNextStep is used in parallel
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const optimisticNextStepDeprecated = buildNextStepNew({
	report: {...report, policyID: policy.id},
	predictedNextStatus: newStatusNum,
	policy,
	currentUserAccountIDParam: currentUserAccountID,
	currentUserEmailParam: email,
	hasViolations: hasViolationsParam,
	isASAPSubmitBetaEnabled,
	});
	const optimisticNextStep = buildOptimisticNextStep({
	report: {...report, policyID: policy.id},
	predictedNextStatus: newStatusNum,
	policy,
	currentUserAccountIDParam: currentUserAccountID,
	currentUserEmailParam: email,
	hasViolations: hasViolationsParam,
	isASAPSubmitBetaEnabled,
	});
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${reportID}`,
	value: optimisticNextStepDeprecated,
	});
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	nextStep: optimisticNextStep,
	pendingFields: {
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	},
	});
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	pendingFields: {
	nextStep: null,
	},
	},
	});
	// @ts-expect-error - will be solved in https://github.com/Expensify/App/issues/73830
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${reportID}`,
	value: reportNextStep,
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	nextStep: report.nextStep ?? null,
	pendingFields: {
	nextStep: null,
	},
	},
	});
	}

function buildOptimisticChangePolicyData(
    report: Report,
    policy: Policy,
    currentUserAccountID: number,
    email: string,
    hasViolationsParam: boolean,
    isASAPSubmitBetaEnabled: boolean,
    isReportLastVisibleArchived: boolean | undefined,
    reportNextStep?: ReportNextStepDeprecated,
    optimisticPolicyExpenseChatReport?: Report,
) {
    const optimisticData: Array<
        OnyxUpdate<
            | typeof ONYXKEYS.COLLECTION.REPORT
            | typeof ONYXKEYS.COLLECTION.SNAPSHOT
            | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
            | typeof ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS
            | typeof ONYXKEYS.COLLECTION.NEXT_STEP
            | typeof ONYXKEYS.COLLECTION.TRANSACTION
        >
    > = [];
    const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION>> = [];
    const failureData: Array<
        OnyxUpdate<
            | typeof ONYXKEYS.COLLECTION.REPORT
            | typeof ONYXKEYS.COLLECTION.NEXT_STEP
            | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
            | typeof ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS
            | typeof ONYXKEYS.COLLECTION.TRANSACTION
        >
    > = [];

    const reportID = report.reportID;
    const reportIDToThreadsReportIDsMap = buildReportIDToThreadsReportIDsMap();
    updatePolicyIdForReportAndThreads(reportID, policy.id, reportIDToThreadsReportIDsMap, optimisticData, failureData);

    // Compute the manager/approver for the destination workspace (policy).
    const reportForDestinationPolicy = {...report, policyID: policy.id};
    const destinationManagerID = getNextApproverAccountID(reportForDestinationPolicy);
    const shouldUpdateManagerForSubmittedReport = isProcessingReport(report) && destinationManagerID && report.managerID !== destinationManagerID;

    if (shouldUpdateManagerForSubmittedReport) {
        optimisticData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {managerID: destinationManagerID},
        });
        failureData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {managerID: report.managerID},
        });
    }

    // Existing logic: reopen if manager isn't a member of destination policy.
    let newStatusNum = report?.statusNum;
    const isOpenOrSubmitted = isOpenExpenseReport(report) || isProcessingReport(report);
    const managerLogin = PersonalDetailsUtils.getLoginByAccountID(report.managerID ?? CONST.DEFAULT_NUMBER_ID);
    if (isOpenOrSubmitted && managerLogin && !isPolicyMember(policy, managerLogin)) {
        newStatusNum = CONST.REPORT.STATUS_NUM.OPEN;
        optimisticData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {
                stateNum: CONST.REPORT.STATE_NUM.OPEN,
                statusNum: CONST.REPORT.STATUS_NUM.OPEN,
                managerID: destinationManagerID ?? report.managerID,
            },
        });

        failureData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {
                stateNum: report.stateNum,
                statusNum: report.statusNum,
                managerID: report.managerID,
            },
        });
    }

    if (newStatusNum != null) {
        const reportForNextStep: Report = {
            ...report,
            policyID: policy.id,
            managerID: shouldUpdateManagerForSubmittedReport ? destinationManagerID : report.managerID,
        };

        const optimisticNextStepDeprecated = buildNextStepNew({
            report: reportForNextStep,
            predictedNextStatus: newStatusNum,
            policy,
            currentUserAccountIDParam: currentUserAccountID,
            currentUserEmailParam: email,
            hasViolations: hasViolationsParam,
            isASAPSubmitBetaEnabled,
        });
        const optimisticNextStep = buildOptimisticNextStep({
            report: reportForNextStep,
            predictedNextStatus: newStatusNum,
            policy,
            currentUserAccountIDParam: currentUserAccountID,
            currentUserEmailParam: email,
            hasViolations: hasViolationsParam,
            isASAPSubmitBetaEnabled,
        });

        optimisticData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${reportID}`,
            value: optimisticNextStepDeprecated,
        });
        optimisticData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {
                nextStep: optimisticNextStep,
                pendingFields: {nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE},
            },
        });
        // ... existing success/failure handling remains unchanged ...
    }

    return {optimisticData, successData, failureData, optimisticReportPreviewAction, optimisticMovedReportAction};
}

What alternative solutions did you explore? (Optional)

[nkdengineer]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-02 10:14:54 UTC.

Proposal

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

For Admin: Approve button and option are not displayed, system message says "Waiting for Member to approve expenses". Reject option is not available in the expense details
For Member: Approve button is displayed, but system message says "Waiting for Admin to approve expenses".

What is the root cause of that problem?

After the report is submitted, the mangerID of the expense report is the member. Because the member is already a member of the workspace, the report's manager isn't changed, and then the admin can't see the approve/reject button.

App/src/libs/actions/Report.ts

Line 5860 in 0564536

if (isOpenOrSubmitted && managerLogin && !isPolicyMember(policy, managerLogin)) {

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

1. We should change the mangerID of the expense report to the new manager of the new policy. And then we don't need to update managerID in this block anymore

const newManagerAccountID = getNextApproverAccountID({...report, policyID: policy.id});
if (isProcessingReport(report) && newManagerAccountID !== report.managerID) {
        optimisticData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {
                managerID: newManagerAccountID,
            },
        });

        failureData.push({
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
            value: {
                managerID: report.managerID,
            },
        });
    }

App/src/libs/actions/Report.ts

Line 5860 in 0564536

if (isOpenOrSubmitted && managerLogin && !isPolicyMember(policy, managerLogin)) {

2. Important change: The first point is only the optimistic data, we need to handle the same from the backend side in ChangeReportPolicy API to update mangerID of member's expense report to manger of the new policy then it can work on the admin side

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[DylanDylann]

@annaweber830 Please avoid posting large code blocks, a short pseudo-code snippet would be enough to illustrate the proposed changes. For anything more detailed, a test branch would be preferred.

[DylanDylann]

@annaweber830 @nkdengineer Can you clarify the impact of updating optimistic data? I assume you want to update the primary action and next step message in the member account while awaiting the response. It will be better to share a video after your change. Also, please detail what changes are needed from BE to make this work.

[nkdengineer]

@DylanDylann Here is the result. The next step and primary action will be updated accordingly when the manger data is correct. Also updated the backend change detail

Screen.Recording.2026-02-02.at.17.28.24.mov

[DylanDylann]

@nkdengineer's proposal looks good to me

🎀👀🎀 C+ reviewed