[$250] Reports - Member can submit expense after leaving WS chat and pay button is unresponsive

[vincdargento]

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.95-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2219752/test-runs/TR-289/folder/13177080/41237961/842125606
Email or phone of affected tester (no customers): ibellicotest+1606@gmail.com
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 / Android 12 / Chrome ( mWeb / Hybrid app) - Windows 10 / Chrome
App Component: Search

Action Performed:

Prerequisite: Have two accounts opened on two different devices or environments.
Prerequisite 2: User A has at least one workspace available.
Prerequisite 3: Delayed submissions and approvals enabled.

1. Open the Expensify app.
2. Navigate to "Workspaces" and open any workspace.
3. Tap on "Members" and invite User B as member of the workspace.
4. As User B, open the new workspace chat and create a manual expense.
5. Navigate to "Workspaces" and leave the workspace.
6. Navigate to "Reports" > "Submit"
7. Note that expense is still displayed.
8. Tap on "Submit"
9. Navigate to "Pay" section.
10. Open the expense and tap on the "Pay" button.
11. Tap on "Mark as paid"
12. Note that no action is triggered after tapping on "Mark as paid"
13. Tap on "More" and select "Undo Close"
14. Tap on "More" again and delete the expense.
15. Note that a "It´s not here" page it´s displayed.

Expected Result:

After member leaves the workspace, created expenses shouldn´t be available to be submitted anymore, and the "Pay" option shouldn´t be available either.

Actual Result:

After member leaves the workspace, created expenses are still displayed on "Submit" section on "Reports" and can be submitted. After this action, expense can be found on "Pay" section, but no action is triggered when selecting the "Mark as paid" option.
Also, if the user taps on "Undo Close" and deletes the expense, a "It´s not here" page appears.

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

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021957455155590583053
• Upwork Job ID: 1957455155590583053
• Last Price Increase: 2025-09-01

Issue Owner

Current Issue Owner: @nkuoch

[melvin-bot]

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

[lorretheboy]

Proposal

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

Reports - Member can submit expense after leaving WS chat and pay button is unresponsive

What is the root cause of that problem?

The issue occurs when a user leaves a workspace but their expenses remain accessible in the app. The problem stems from insufficient workspace membership validation in several key areas:

• The isPayer function only checked if a user had admin role in a policy, but didn't validate if they were still an active member of the workspace.
• The expense filtering logic didn't properly validate current user membership when determining which reports to show.
• The canIOUBePaid function relied on the isPayer function without additional membership checks.

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

Add here. Check to ensure the current user is still a member of the workspace

    if (iouReport?.policyID && policy?.type !== CONST.POLICY.TYPE.PERSONAL) {
        const isCurrentUserPolicyMember = isPolicyMember(currentUserEmail, iouReport.policyID);
        if (!isCurrentUserPolicyMember) {
            return false;
        }
    }

Add here as well

    if (iouReport?.policyID && policyType !== CONST.POLICY.TYPE.PERSONAL) {
        const isPolicyMemberResult = isPolicyMember(session?.email, iouReport.policyID);
        if (!isPolicyMemberResult) {
            return false;
        }
    }

Can update filterReportsByPolicyIDAndMemberAccountIDs to

/**
 * Checks if the current user can access a report based on workspace membership.
 * This function validates that the user is still a member of the workspace for workspace-related reports.
 */
function canCurrentUserAccessReport(report: OnyxEntry<Report>): boolean {
    // Allow access to non-workspace reports (DMs, etc.)
    if (!report?.policyID || report.policyID === CONST.POLICY.ID_FAKE) {
        return true;
    }

    if (isConciergeChatReport(report)) {
        return true;
    }

    // For workspace reports, check if the current user is still a member
    return isPolicyMember(currentUserPersonalDetails?.login, report.policyID);
}

/**
 * Given an array of reports, return them filtered by a policyID and policyMemberAccountIDs.
 */
function filterReportsByPolicyIDAndMemberAccountIDs(reports: Array<OnyxEntry<Report>>, policyMemberAccountIDs: number[] = [], policyID?: string) {
    return reports.filter((report) => {
        if (!report) {
            return false;
        }

        // First check if the report belongs to the workspace
        const belongsToWorkspace = doesReportBelongToWorkspace(report, policyMemberAccountIDs, policyID);
        if (!belongsToWorkspace) {
            return false;
        }

        // Then check if the current user can still access this report
        return canCurrentUserAccessReport(report);
    });
}

App/src/libs/ReportUtils.ts

Lines 1813 to 1815 in e037dce

	function filterReportsByPolicyIDAndMemberAccountIDs(reports: Array<OnyxEntry<Report>>, policyMemberAccountIDs: number[] = [], policyID?: string) {
	return reports.filter((report) => !!report && doesReportBelongToWorkspace(report, policyMemberAccountIDs, policyID));
	}

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

Can add tests to cover new function

What alternative solutions did you explore? (Optional)

NA

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.

[melvin-bot]

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

[melvin-bot]

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

[shubham1206agra]

Need to check internally - Why are we still getting policy.role as admin? It should be undefined.

🎀👀🎀 C+ reviewed