[$250] Admin unable to access report in New Expensify that is visible in Classic

[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: 9.3.57-1
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log into New Expensify as an admin.
2. Attempt to open a specific expense report.
3. Observe the error message.
4. Log into Expensify Classic.
5. Navigate to the same report.
6. Confirm that the report is visible and accessible in Classic.

Expected Result:

The admin should be able to access the same report in both Classic and New Expensify.
Report visibility and permissions should be consistent across platforms.

Actual Result:

In New Expensify, the admin receives the error: “Hmm... it's not here. This chat or expense may have been deleted or you do not have access to it.”
In Classic, the report is accessible without issues.

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 screenshot for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @francoisl

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042976567746112546
• Upwork Job ID: 2042976567746112546
• Last Price Increase: 2026-04-18

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user navigates to a report in New Expensify, the ReportFetchHandler (App/src/pages/inbox/ReportFetchHandler.tsx:102) calls openReport(), which sends the OpenReport command to the backend. The backend checks whether the user has access to the report and, if access is denied, returns Onyx data that sets errorFields.notFound on the report object. The frontend's canAccessReport() (App/src/libs/ReportUtils.ts:9100-9111) then returns false, and ReportNotFoundGuard (App/src/pages/inbox/ReportNotFoundGuard.tsx:56) renders the "Hmm... it's not here" page.

The likely discrepancy is in how the backend's OpenReport command checks access vs. how Classic determines report visibility. In New Expensify, report access is participant-based — isReportParticipant() (App/src/libs/ReportUtils.ts:10733-10745) only considers users in report.participants, ownerAccountID, and managerID. It does not account for workspace admins who aren't direct participants. In Classic, workspace admins can typically view all expense reports in their workspace regardless of participant status. If the backend OpenReport command uses a similar participant-only check, a workspace admin who isn't explicitly a participant/owner/manager of a specific expense report would get notFound — even though Classic's broader policy-admin-aware visibility would show the same report.

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

The backend OpenReport command's access check should grant access to workspace admins for expense reports within their workspace, matching Classic's behavior. The backend code would need to check the user's policy role (admin/owner) in addition to participant membership when determining access.

On the frontend side, no changes should be needed — the frontend already defers to the backend's errorFields.notFound flag. Once the backend correctly grants access, the flag won't be set and the report will render normally.

Note: This analysis is medium confidence because the backend OpenReport handler code is not available for direct inspection. The hypothesis is based on the frontend's access model and the described symptoms. Backend investigation is needed to confirm.

What alternative solutions did you explore? (Optional)

An alternative would be to add a frontend fallback that checks policy admin status before showing the not-found page — but this would be a workaround. The backend is the source of truth for access, so the fix should be there.

Investigation details

Error flow:

1. User navigates to /r/REPORT_ID → ReportFetchHandler calls openReport()
2. Backend OpenReport checks access → returns errorFields.notFound in Onyx data if denied
3. canAccessReport() sees errorFields.notFound → returns false
4. ReportNotFoundGuard shows "Hmm... it's not here" with subtitle "This chat or expense may have been deleted or you do not have access to it."

Key code locations:

• Error strings: App/src/languages/en.ts:3386-3388
• Access check: App/src/libs/ReportUtils.ts:9100-9111 (canAccessReport)
• Participant check: App/src/libs/ReportUtils.ts:10733-10745 (isReportParticipant)
• Not-found guard: App/src/pages/inbox/ReportNotFoundGuard.tsx:56-61
• Report fetch trigger: App/src/pages/inbox/ReportFetchHandler.tsx:102-126
• OpenReport success data clears notFound: App/src/libs/actions/Report/index.ts:1326-1334

Alternative explanations considered:

• Race condition where isLoading becomes false before OpenReport response arrives — unlikely since ReportNotFoundGuard checks isLoadingReportData from isLoadingApp and report metadata loading state
• Report was actually deleted — ruled out since it's visible in Classic
• Beta-gated default room — the report is an expense report, not a default room

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @ghmaimon Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[ghmaimon]

Proposal

What is the root cause of that problem?

When an admin opens an expense report in NewDot, the backend's OpenReport command only grants access if the user is a direct participant, owner, or manager of that report. If the admin doesn't match any of those, the backend returns errorFields.notFound: true. The frontend then calls canAccessReport() in ReportUtils.ts, sees that flag, and shows the "Hmm... it's not here" page.

In Classic, workspace admins can access all expense reports belonging to their workspace regardless of direct participation. NewDot's backend check doesn't replicate this rule, which is the root cause.

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

Two changes:

1. The backend OpenReport handler should grant access to policy admins and owners for reports in their workspace, the same way Classic does.

2. In canAccessReport() in ReportUtils.ts, add a check so that if the current user is a policy admin for the report's workspace, the notFound flag is ignored and access is returned as true. This keeps the frontend gate consistent with the backend fix and also unlocks report links in ReportActionItemParentAction which uses the same function.

What alternative solutions did you explore? (Optional)

• Patching withReportOrNotFound and withReportAndReportActionOrNotFound directly instead of canAccessReport — would need two separate changes instead of fixing the shared function.
• Checking policy admin status only in ReportNotFoundGuard — that component doesn't use canAccessReport, so it wouldn't fix the actual screen gate.
• Sending an isAdmin flag from the frontend in the OpenReport request — trusting a client-supplied privilege flag is a security risk.

[github-actions]

⚠️ @ashu75575 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.