Web - Workspace - CMD+B opens not here page for archived #admins room or workspace chat

[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.4.0-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92064
Email or phone of affected tester (no customers): osidnjosjoidjiosjdo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Chat Report View

Action Performed:

1. Go to staging.new.expensify.com
2. Create a workspace.
3. Delete the workspace.
4. Open the archived #admins room or workspace chat.
5. Press CMD+B.

Expected Result:

CMD+B should do nothing for archived #admins room or workspace chat.

Actual Result:

CMD+B opens not here page for archived #admins room or workspace chat.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172883_1780683528881.7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7172883

[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/96796a90014384ebf5551f552cdbf056544d224821f4123d62b942ec79574367

[melvin-bot]

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

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

Proposal

What is the root cause of that problem?

The CMD+B ("Go to workspace") shortcut added in #92064 only guards against a missing or fake policyID before navigating — it never checks whether the policy is actually still accessible.

When a workspace is deleted, its #admins room / workspace chat becomes archived but the report still carries the old policyID. So the handler resolves a policyID, passes the !policyID || policyID === ID_FAKE guard, and navigates to the workspace page:

Handler logic (the incomplete guard)

GoToWorkspaceHandler.tsx:28-35

const report = getReportOrDraftReport(reportID);
const policyID = report?.policyID ?? (report?.parentReportID ? getReportOrDraftReport(report.parentReportID)?.policyID : undefined);
if (!policyID || policyID === CONST.POLICY.ID_FAKE) {
    return;
}
// navigates even when the policy is deleted/inaccessible ↓
const route = shouldUseNarrowLayoutRef.current ? ROUTES.WORKSPACE_INITIAL.getRoute(...) : ROUTES.WORKSPACE_OVERVIEW.getRoute(policyID);
Navigation.navigate(route);

The destination workspace page is wrapped in AccessOrNotFoundWrapper, which gates rendering on exactly the check the shortcut is missing — AccessOrNotFoundWrapper.tsx:203 calls isPolicyAccessible(policy, login) and shows the "not here" FullPageNotFoundView when it returns false. For a deleted workspace the policy is gone / has pendingAction: DELETE, so isPolicyAccessible returns false — hence the "not here" page instead of doing nothing.

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

In GoToWorkspaceHandler.tsx, add the same accessibility check the destination page uses, before navigating:

1. Resolve the policy from the policyID (getPolicy(policyID) / PolicyUtils.getPolicy).
2. return early when !isPolicyAccessible(policy, currentUserLogin).

isPolicyAccessible already covers both deleted-workspace cases (policy removed from Onyx → empty object → false; policy lingering with pendingAction: DELETE or no role → false), so it makes CMD+B do nothing for archived/deleted-workspace chats while still working for live workspaces.

Implementation note: the shortcut callback is registered once in a useEffect, so the current user login should be captured via a ref (mirroring the existing shouldUseNarrowLayoutRef pattern) using useCurrentUserPersonalDetails() so it's current when the shortcut fires.

What alternative solutions did you explore? (Optional)

Guarding on isArchivedReport / useReportIsArchived for the report would also stop the navigation for this specific repro, but isPolicyAccessible is the more precise root-cause fix — it mirrors the exact gate on the destination page and also handles non-archived "policy I can no longer access" cases. The two could be combined, but isPolicyAccessible alone is sufficient.

Confidence: High — isPolicyAccessible is literally the function the destination page uses to decide whether to render the "not here" view, confirmed at AccessOrNotFoundWrapper.tsx:203.

---

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

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[godzillaxbox19982014-lgtm]

Proposal

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

Web - Workspace - CMD+B opens not here page for archived #admins room or workspace chat

What is the root cause of that problem?

I traced this to the path that handles workspace name, CMD, iOS:

• src/pages/inbox/report/SystemChatReportFooterMessage.tsx:50 (matching code path): adminReportName: adminChatReport?.reportName ?? CONST.REPORT.WORKSPACE_CHAT_ROOMS.ADMINS,
• src/pages/ReimbursementAccount/VerifiedBankAccountFlowEntryPoint.tsx:101 (isCurrentUserPolicyAdminSelector): const isCurrentUserPolicyAdminSelector = (policies: OnyxCollection<OnyxTypes.Policy>) => hasActiveAdminWorkspaces(currentUserLogin, policies);
• src/pages/workspace/workflows/WorkspaceWorkflowsPayerPage.tsx:142 (getPayersAndAdmins): const [formattedPolicyAdmins, formattedAuthorizedPayer] = getPayersAndAdmins();
• The local evidence matches this recurring failure shape: route params are created in one format and read in another. Here, src/pages/inbox/report/SystemChatReportFooterMessage.tsx:50 and src/pages/ReimbursementAccount/VerifiedBankAccountFlowEntryPoint.tsx:101 do not agree on the same workspace name, CMD, iOS value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/inbox/report/SystemChatReportFooterMessage.tsx:50 to derive workspace name, CMD, iOS from the route/access source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/ReimbursementAccount/VerifiedBankAccountFlowEntryPoint.tsx:101; that follows the safer family move to fix the route builder/consumer pair instead of adding a screen-only redirect, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Navigation, RHP, Not Here, Back Stack surface and avoid changing deep links, auth/onboarding redirects.

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

1. Add or update a regression in tests/navigation/**/*.ts for the exact issue flow: Web - Workspace - CMD+B opens not here page for archived #admins room or workspace chat.
2. Cover the counter-case near src/pages/inbox/report/SystemChatReportFooterMessage.tsx:50 so valid existing workspace name, CMD, iOS behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name, CMD, iOS consistent at the first read/write boundary shown above.

[truph01]

We already aware of this issue when implementing it #92064 (comment)