[$250] Paid reports filter in New Expensify only shows admin’s own reports, not all workspace reports

[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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs reproduction
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: @rairibeiro
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log into New Expensify as a workspace admin
2. Go to the Reports page
3. Select the workspace from filter pill
4. Apply filters to show Paid reports, and (optionally) specify a date range
5. Observe the list of results
6. In Expensify Classic, apply the same workspace and date filters for Paid reports and compare the results.

Expected Result:

In New Expensify, the Paid reports filter for a workspace should return all Paid reports for all users in that workspace, matching what the admin can see in Expensify Classic.
Admins should be able to filter by workspace and dates and see all relevant reports for that workspace.

Actual Result:

In New Expensify, the admin sees only their own Paid reports under the workspace, even though they can see all employees’ Paid reports in Expensify Classic using the same filters.
The same workspace and date filters produce different visibility results between Classic and New Expensify.

Workaround:

Unknown

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

The video for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ZhenjaHorbach

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022021595741424230807
• Upwork Job ID: 2021595741424230807
• Last Price Increase: 2026-02-18

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[MassoudFSharifi]

Proposal

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

In New Expensify, admins filtering Paid reports by workspace and date range are not getting the same report set they can see in Expensify Classic.
With equivalent filters, New Expensify omits expected workspace reports, creating a visibility mismatch between products.

What is the root cause of that problem?

New Expensify was sending date-only boundary filters with strict operators to Search API:

• date < YYYY-MM-DD (exclusive end)
• date > YYYY-MM-DD (exclusive start)

This excluded reports on boundary dates, while Classic behavior for day-based ranges is inclusive.

Code path in src/libs/actions/Search.ts

So date boundaries were forwarded without normalization, creating different results vs Classic.

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

Normalize API-bound date filters for date-only values to inclusive boundaries:

• < YYYY-MM-DD -> <= YYYY-MM-DD
• > YYYY-MM-DD -> >= YYYY-MM-DD

Implementation in src/libs/SearchQueryUtils.ts

Then apply it in src/libs/actions/Search.ts before sending jsonQuery:

This keeps user-visible query text unchanged while aligning New Expensify API behavior with Classic.

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

None

What alternative solutions did you explore? (Optional)

• Convert date upper bounds to next-day exclusive timestamps (< nextDay) and lower bounds to prior-day adjustments, but this is less explicit and more timezone-sensitive.
• Backend-only normalization, which also works but is outside this client-side fix scope.

[melvin-bot]

📣 @MassoudFSharifi! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[yatin-italy]

Proposal

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

In New Expensify, when a workspace admin applies workspace + Paid (and optionally a date range), they see only their own paid reports, but in Expensify Classic the same workspace and date filters show all paid reports for all users in that workspace.

What is the root cause of that problem?

In this flow, the earliest incorrect technical assumption is in the Search API behavior used by search() in src/libs/actions/Search.ts, where the backend assumes an expense-report search with status = paid should be restricted to ownerAccountID === currentUser even when policyID is present and the user has access to that workspace, so the API returns a user-scoped result set instead of a workspace-scoped one and the client cannot expand the result set because it does not add an implicit owner filter and it does not filter results by owner.

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

1. Issue and root cause
   Issue: With workspace + Paid (and optional date range), admins see only their own Paid reports in New Expensify, while Classic shows all Paid reports for that workspace.
   Root cause: This is a visibility/scope bug: the Search API is returning only the current user’s reports instead of all workspace reports the user is allowed to see. The client already sends policyID when a workspace is selected and does not add an implicit “from”/owner filter or filter results by owner. So the fix for “only my reports” has to be in the backend (Search API). The client can only ensure the request is correct and robust.

2. Backend fix (Search API – no code in this repo)
   The service that implements Search (the one that handles READ_COMMANDS.SEARCH and the jsonQuery payload) must:
   For type = expense report, status = paid, and policyID present:
   Return all reports in that policy that the current user is allowed to see (e.g. for a workspace admin: all workspace Paid reports), not only reports where ownerAccountID === currentUser.
   Use policyID in the request as the workspace scope; do not restrict to current user’s reports when policyID is set and the user has access to that workspace.
   Implementation details (where to relax owner filtering, how to apply policy membership, etc.) belong in the backend codebase that owns Search.

3. Client-side code changes (App repo)
   These changes do not fix “only my reports” by themselves; they make the client request explicit and robust so that:
   policyID is guaranteed to be on the Search payload when the user has selected a workspace.
   It’s clear that we must not send an implicit owner scope for workspace-scoped report search.

3.1 Ensure policyID is always on the Search payload when present (src/libs/actions/Search.ts)
Location: search() function, where query is built (around lines 435–445).
Current code:

    const {flatFilters, limit, ...queryJSONWithoutFlatFilters} = queryJSON;    const query = {        ...queryJSONWithoutFlatFilters,        searchKey,        offset,        filters: queryJSONWithoutFlatFilters.filters ?? null,        shouldCalculateTotals,        // Backend expects 'maximumResults' instead of 'limit'        ...(limit !== undefined && {maximumResults: limit}),    };    const jsonQuery = JSON.stringify(query);

Change: Guarantee that when the user has selected a workspace, policyID is always sent. Avoid relying only on spread order so a future refactor can’t drop it.
Replace the above with:

    const {flatFilters, limit, ...queryJSONWithoutFlatFilters} = queryJSON;    const query = {        ...queryJSONWithoutFlatFilters,        searchKey,        offset,        filters: queryJSONWithoutFlatFilters.filters ?? null,        shouldCalculateTotals,        // Backend expects 'maximumResults' instead of 'limit'        ...(limit !== undefined && {maximumResults: limit}),        // Ensure workspace scope is always sent when user selected a workspace (fixes #82141: backend must return all workspace reports, not only current user's)        ...(queryJSON.policyID?.length ? {policyID: queryJSON.policyID} : {}),    };    const jsonQuery = JSON.stringify(query);

Why: Makes the “workspace scope” part of the contract explicit and ensures policyID is on the payload whenever the user has selected a workspace, regardless of how queryJSONWithoutFlatFilters is built later.

3.2 Do not add an implicit “from” when only workspace is selected (verification / comment)
Location: Same file, near the same query construction (e.g. right before or after the block above).
Add a short comment so future changes don’t add an implicit owner filter for workspace-only searches:

    // When policyID is set, scope is workspace-wide; do not add implicit from/owner filter (see #82141).

Why: Documents that workspace-scoped search must not be narrowed to the current user on the client.

4. What this solution does and doesn’t do
   Backend: Fixes the bug by changing Search API behavior so workspace + Paid returns all workspace Paid reports for the user.
   Client:
   Ensures the client always sends policyID when a workspace is selected (no accidental drop).
   Documents that we must not add an implicit “from” for workspace scope.
   Does not: Change date logic, add new shared date utilities, or touch other search flows. No global date-operator normalization.

5. How to verify
   Backend: For a workspace admin, run the same Search (workspace + Paid, same date range) from New Expensify and Classic; compare API request/response. After the backend fix, New Expensify’s response should include all workspace Paid reports, like Classic.
   Client: After the change in 3.1, run a workspace + Paid search and confirm the request body includes policyID (e.g. via network tab or backend logs).

6. Summary of edits
   File Change
   src/libs/actions/Search.ts In search(), add explicit policyID to query when queryJSON.policyID?.length is truthy, and add the one-line comment about not adding implicit from for workspace scope.

This is the complete solution: backend fix specification plus minimal, localized client code changes that support the correct behavior and avoid regressions. I'm in Ask mode, so I can’t apply the edits; you can paste the snippet above into Search.ts or switch to Agent mode if you want the tool to apply it.

[HiepPP]

Proposal

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

When a workspace admin filters for Paid reports by workspace in New Expensify, they only see their own Paid reports. In Expensify Classic, the same filters show all Paid reports for all workspace members. This is a visibility/scope mismatch between Classic and New Expensify.

What is the root cause of that problem?

The client correctly sends policyID, type, and status to the backend Search API without any user-scoping restriction. The backend is the one restricting results to the current user's own reports.

The search() function builds the query by spreading queryJSONWithoutFlatFilters (which includes policyID) into the API payload:

App/src/libs/actions/Search.ts

Lines 438 to 449 in 1d699f9

	const {optimisticData, finallyData, failureData} = getOnyxLoadingData(queryJSON.hash, queryJSON, offset, isOffline, true);
	const {flatFilters, limit, ...queryJSONWithoutFlatFilters} = queryJSON;
	const query = {
	...queryJSONWithoutFlatFilters,
	searchKey,
	offset,
	filters: queryJSONWithoutFlatFilters.filters ?? null,
	shouldCalculateTotals,
	// Backend expects 'maximumResults' instead of 'limit'
	...(limit !== undefined && {maximumResults: limit}),
	};
	const jsonQuery = JSON.stringify(query);

No ownerAccountID or user-scoping filter is added anywhere in the client code path. The policyID is correctly normalized to an array and included in every query:

App/src/libs/SearchQueryUtils.ts

Lines 467 to 469 in 1d699f9

	if (result.policyID && typeof result.policyID === 'string') {
	// Ensure policyID is always an array for consistency
	result.policyID = [result.policyID];

And serialized into the query string:

App/src/libs/SearchQueryUtils.ts

Lines 528 to 530 in 1d699f9

	if (queryJSON?.policyID) {
	queryParts.push(`${CONST.SEARCH.SYNTAX_FILTER_KEYS.POLICY_ID}:${Array.isArray(queryJSON.policyID) ? queryJSON.policyID.join(',') : queryJSON.policyID}`);
	}

The backend Search API endpoint applies a default user-scope restriction that limits results to reports where ownerAccountID === currentUser, even when policyID is present and the requesting user is a workspace admin. It does not expand visibility to include all workspace members' reports the way Classic does.

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

This is a backend fix. The backend Search API needs to check whether the requesting user has admin access to the workspace specified by policyID. When they do, it should return all workspace members' reports matching the filters instead of restricting to the current user's reports only.

No client-side changes are needed in the App repo. The client already sends the correct query with policyID included. The getSections() function in SearchUIUtils.ts displays whatever the backend returns without applying any user-scoping filter.

What alternative solutions did you explore? (Optional)

I verified whether the client might be missing policyID from the query payload (as suggested in another proposal). Code analysis confirms policyID flows through the entire pipeline:

1. Filter form stores it under FILTER_KEYS.POLICY_ID
2. buildQueryStringFromFilterFormValues() converts it to policyID:ABC123
3. buildSearchQueryJSON() parses and normalizes it to an array
4. search() includes it via spread into the serialized jsonQuery

The client code is correct. A client-side defensive change to "ensure policyID is included" would be redundant.