Expense - Change Workspace option available for submitted expense

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: v9.1.25-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: No, reproducible on hybrid only
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5901011
Issue reported by: Applause Internal Team
Device used: Windows 10 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition: Employee has 2 workspaces

1. Open the First WS with 2 expenses in submitted and submit status
2. Click on the More button on the expense in the Submitted status
3. Click on the Change Workspace
4. Change the submitted expense to the second workspace
5. Click on the More button on the expense in the Submit status
6. Click on the Change Workspace
7. Select the second workspace

Expected Result:

The change workspace option only displays for an expense in the Submit status

Actual Result:

The change workspace option display for a submitted expense and after click on it display an error message

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6796887_1744185652889.Change_WS.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @grgia (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[grgia]

Potential RCA: #58084

[jnowakow]

According to design doc it's correct behaviour. I've asked it here https://docs.google.com/document/d/1JZLr_5gX348cMZXNr6HUwi4QscOcDg3IY368FMAu3H4/edit?disco=AAABgi2j1Cc
cc @luacmartins

[ChavdaSachin]

Proposal

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

Change Workspace option available for submitted expense

What is the root cause of that problem?

RCA for this issue is, whether change workspace option should be visible or not is determined from ReportSecondaryActionUtils.isChangeWorkspaceAction function.
In which change workspace is made visible even when report is processing ie. submitted/approved but not paid yet.

App/src/libs/ReportSecondaryActionUtils.ts

Lines 284 to 288 in 9298e72

	const isProcessingReport = isProcessingReportUtils(report);
	if (isReportSubmitter && (isOpenReport || isProcessingReport)) {
	return true;
	}

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

Remove isProcessingReport and isReportApproved checks here and only show change workspace option for open or closed reports.

    const isOpenReport = isOpenReportUtils(report);

    if (isReportSubmitter && isOpenReport) {
        return true;
    }

    const isReportApprover = isApproverUtils(policy, getCurrentUserAccountID());
    const isReportPayer = isPayerUtils(getSession(), report, false, policy);

    if (isReportPayer && isClosedReport) {
        return true;
    }

App/src/libs/ReportSecondaryActionUtils.ts

Lines 283 to 301 in 9298e72

	const isOpenReport = isOpenReportUtils(report);
	const isProcessingReport = isProcessingReportUtils(report);
	if (isReportSubmitter && (isOpenReport || isProcessingReport)) {
	return true;
	}
	const isReportApprover = isApproverUtils(policy, getCurrentUserAccountID());
	if (isReportApprover && isProcessingReport) {
	return true;
	}
	const isReportPayer = isPayerUtils(getSession(), report, false, policy);
	const isReportApproved = isReportApprovedUtils({report});
	if (isReportPayer && (isReportApproved || isClosedReport)) {
	return true;
	}

Also remove isReportApproved check here.

App/src/libs/ReportSecondaryActionUtils.ts

Line 313 in 9298e72

const isReportFinished = isReportApproved || isReportReimbursed || isClosedReport;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

NA

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[luacmartins]

FYI we reverted the original offending PR

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[luacmartins]

This is expected. Users can change the workspace on a report up until the report has one level of approval on it.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.26-10 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [CP Staging] Revert "Simplified actions on report header" #59931

If no regressions arise, payment will be issued on 2025-04-18. 🎊

[luacmartins]

I'm gonna reopen this since it's still happening. I'm seeing a 401 Not allowed to set this magic reportNameValuePair error in the API. I'll take a look at it.

[luacmartins]

I'm unable to reproduce this. Closing.