Workspace - Not here page opens when opening workspace settings

[applause-bot]

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.91-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86365
Email or phone of affected tester (no customers): applausetester+khcategory19@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Log out if logged in.
3. Log in to account with many workspaces (eg, applausetester+khcategory19@applause.expensifail.com).
4. Go to Workspaces tab.
5. Open a few workspaces.

Expected Result:

Workspace settings will load without issue.

Actual Result:

Not here page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169351_1780385318806.12.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7169351

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f1037cd73da1ca490a715159a80f70b5e63c2ffa37eea2eaa588b588f82cb510

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #86365

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

[MelvinBot]

🤖 Analysis

This is a regression from #91305 ("Implement read-only access to workspace pages") — not #86365 that Melvin auto-assigned. Both shipped in 9.3.91-0, which is why it reproduces on staging but not production.

Proposal

What is the root cause of that problem?

Expensify/App#91305 added policyFeature={CONST.POLICY.POLICY_FEATURE.OVERVIEW} to the workspace settings page (WorkspaceOverviewPage.tsx:680). That switches the page's visibility gate to the new canMemberRead() permission check at WorkspacePageWithSections.tsx:175.

canMemberRead resolves the user's role with getPolicyRole(policy, login, !login) — for a logged-in user the third argument is false, so it ignores the top-level policy.role and reads only policy.employeeList[login].role (getPolicyRole).

The full employeeList is fetched asynchronously on mount (openWorkspaceView). For accounts with many workspaces, OpenApp returns each policy with the top-level role but a not-yet-populated employeeList. During that window getPolicyRole returns undefined → canMemberRead returns false. Because hasAccessToPolicyFeature is then a concrete false, the admin fallback ?? (canEditWorkspaceSettings(...) || shouldShowNonAdmin) never runs (WorkspacePageWithSections.tsx:194-196), so shouldShow becomes true and the page renders "Not here" instead of a loading state. (This also permanently affects a workspace owner who isn't listed in their own employeeList.)

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

Resolve the role with a fallback to the global policy.role when the per-policy employeeList[login].role isn't available — i.e. have hasPolicyFeaturePermission use the global-role fallback (getPolicyRole(policy, login) with shouldCheckGlobalPolicyRole = true, or fall back to policy.role when the employeeList role is undefined). For the current user the two values represent the same role, and policy.role is available immediately from OpenApp, so this closes the load-timing gap and fixes the owner edge case without weakening scoped-role checks (the employeeList role still wins when present).

Alternatively/additionally, WorkspacePageWithSections should treat an unresolved role as "still loading" (show the spinner) rather than "no access" (show "Not here").

Given this is a deploy blocker, the immediate options are revert #91305 or fix-forward with the role fallback above.

Evidence & alternatives considered

• Every role — including USER — grants OVERVIEW READ in ROLE_PERMISSION_BUNDLES, so a fully-loaded policy never denies a member. Denial only occurs when the role can't be resolved → confirms this is a role-resolution / data-load issue, not an intended permission.
• Expensify/App#86365 (auto-assigned; workspaceAccountID→policyAccountID rename) only affects card logic (useWorkspaceAccountID, card-list Onyx keys); it cannot make policy undefined or trip the access gate. Not the cause.
• Expensify/App#90204 (workspaces table) changes list rendering/navigation but doesn't touch the access gate that renders "Not here".
• Confidence: High on the code mechanism. The lazy-employeeList timing is inferred from the fetch-on-mount pattern plus the "many workspaces / staging-only" repro, rather than log-confirmed.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92336) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.