[Due for payment 2025-06-25] [Simplified Actions] Submitter moving a processing report to a workspace the current manager doesn't have access to results in bad UX

[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.1.49-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): ibellicotest+846@gmail.com
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome / Windows 10 - Chrome
App Component: Money Requests

Action Performed:

Prerequisites:

• User A (Submitter) has at least one workspace created where User B (Approver) is not a member.

Case: Submitter moves a processing report to a workspace that isn’t shared with the current managerID of the report.

1. As userA, create and submit an expense to userB
2. Click More > Change workspace
3. Choose the workspace userB is not a member of

Expected Result:

1. The submitter can move the processing report to the “new” workspace, as long as it hasn't had any level of approval yet.
2. When they do, we move the report back to the open state
3. We also unshare the report with the current managerID of the report
4. We then share the report with the new manager (or at least, I think they would have access to it via workspace chat now etc)

Note: We need to handle instant submit workspaces a little differently for now, as we don't support open reports on a workspace with that config yet until @garrettmknight changes are in. As such, for a workspace with instant submit (i.e delayed submission disabled), we should do the following:

• Hide workspaces in the Change workspace list that the report’s current managerID is not a member of either.

Actual Result:

• The report is still shared with the current manager of the report, which results in a few bugs like:
  • unresponsive Approve / Pay button
  • "unavailable workspace" in report title

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

Triggered auto assignment to @trjExpensify (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.

[nyomanjyotisa]

🚨 Edited by proposal-police: This proposal was edited at 2025-05-22 13:56:30 UTC.

Proposal

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

Expense - Submitter of P2P expense is able to change workspace and receiver is unable to pay

What is the root cause of that problem?

We show the change workspace action when isChangeWorkspaceAction is true, and not checking if the current user is part of the workspace

App/src/libs/ReportSecondaryActionUtils.ts

Lines 441 to 443 in 82fa638

	if (isChangeWorkspaceAction(report, policy)) {
	options.push(CONST.REPORT.SECONDARY_ACTIONS.CHANGE_WORKSPACE);
	}

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

Add additional check to make sure current user is part of the workspace if it a workspace report action

if (isChangeWorkspaceAction(report, policy) && ( !policy || isPolicyMember(getLoginByAccountID(getCurrentUserAccountID()), policy?.id))) {
        options.push(CONST.REPORT.SECONDARY_ACTIONS.CHANGE_WORKSPACE);
    }

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

update the test for getSecondaryReportActions to make sure it don't return change workspace when it is a workspace report action and the current user no part of that workspace

What alternative solutions did you explore? (Optional)

Additionally we can also do the same for any other action whenever needed

[trjExpensify]

Been discussing this one here. I've updated the OP with how we want to account for this case.

[melvin-bot]

@trjExpensify, @luacmartins Huh... This is 4 days overdue. Who can take care of this?