Web - Room - CMD+B opens not here page for invited room

[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): sdsonjodjsodjos@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:

Precondition:

• User is invited to a room.

1. Go to staging.new.expensify.com
2. Go to the invited room.
3. Press CMD+B.

Expected Result:

CMD+B should do nothing for invited room.

Actual Result:

CMD+B opens not here page for invited room.

This issue also includes invoice room (as receiver).

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172882_1780683528352.6.mp4

View all open jobs on GitHub

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

[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/3e967cd17103dd6adf97591bfbd05f2d9d9686d9abb6dd7b02429fc647488af9

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

This is a regression from #92064, which introduced the CMD+B ("go to a report's workspace") shortcut.

The handler navigates to the workspace page whenever the report has any policyID, but it never checks whether the current user can actually access that policy:

GoToWorkspaceHandler.tsx — only guards against a missing/fake policyID

const policyID = report?.policyID ?? (report?.parentReportID ? getReportOrDraftReport(report.parentReportID)?.policyID : undefined);
if (!policyID || policyID === CONST.POLICY.ID_FAKE) {
    return;
}
// navigates regardless of whether the user is a member of the policy

GoToWorkspaceHandler.tsx:28-35

For an invited room (a workspace room you were invited to without being a workspace member) and an invoice room as the receiver, the report does have a policyID, but it points to a policy the user has no role in. The workspace page itself gates access with shouldShowPolicy, which returns false when the user has no policy role — so the page renders the "not here" / FullPageNotFoundView:

WorkspaceInitialPage.tsx — shows NotFound when shouldShowPolicy is false

WorkspaceInitialPage.tsx:204-209

The shortcut blindly navigates there, so the user lands on "not here" instead of the expected no-op.

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

In GoToWorkspaceHandler, before navigating, resolve the policy and reuse the same access check the workspace page uses — only navigate when the user can actually open that workspace. Mirror the page's gate so behavior stays consistent:

• Get the policy via getPolicy(policyID) (already exported from ReportUtils.ts:1408, the handler's existing import source).
• Bail out (do nothing) when shouldShowPolicy(policy, getIsOffline(), getCurrentUserEmail()) is false — i.e. the user has no role on the policy.

This makes CMD+B a no-op for invited rooms and invoice rooms (as receiver), matching the expected result, while keeping it working for reports whose workspace the user belongs to.

Since this is a deploy blocker, reverting #92064 is also a valid fast path if a fix can't land in time.

What alternative solutions did you explore? (Optional)

Use isPolicyMember(policy, getCurrentUserEmail()) as the guard. shouldShowPolicy is preferred because it is the exact predicate the workspace page already uses to decide whether to show "not here", so it cannot drift from the page's own access logic (it also correctly handles pending-join and personal-policy edge cases).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92815) 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 - Room - CMD+B opens not here page for invited room

What is the root cause of that problem?

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

• src/pages/workspace/accounting/netsuite/import/NetSuiteImportCustomFieldNew/NetSuiteImportAddCustomSegmentContent.tsx:41 (matching code path): {pageName: CONST.NETSUITE_CONFIG.NETSUITE_ADD_CUSTOM_SEGMENT.PAGE_NAME.INTERNAL_ID, component: CustomSegmentInternalIdStep},
• src/pages/RoomInvitePage.tsx:167 (inviteToRoom): inviteToRoom(report, invitedEmailsToAccountIDs, formatPhoneNumber);
• src/pages/workspace/accounting/qbd/utils.ts:8 (if): if (platform === CONST.PLATFORM.MOBILE_WEB || platform === CONST.PLATFORM.IOS || platform === CONST.PLATFORM.ANDROID) {
• The local evidence matches this recurring failure shape: route params are created in one format and read in another. Here, src/pages/workspace/accounting/netsuite/import/NetSuiteImportCustomFieldNew/NetSuiteImportAddCustomSegmentContent.tsx:41 and src/pages/RoomInvitePage.tsx:167 do not agree on the same 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/workspace/accounting/netsuite/import/NetSuiteImportCustomFieldNew/NetSuiteImportAddCustomSegmentContent.tsx:41 to derive CMD, iOS from the route/access source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/RoomInvitePage.tsx:167; 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 - Room - CMD+B opens not here page for invited room.
2. Cover the counter-case near src/pages/workspace/accounting/netsuite/import/NetSuiteImportCustomFieldNew/NetSuiteImportAddCustomSegmentContent.tsx:41 so valid existing 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 CMD, iOS consistent at the first read/write boundary shown above.

[truph01]

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