[$250] Support login shows workspaces from both support account and user account

[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 (Reproduction blocked)
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: @tgolen
Slack conversation (hyperlinked to channel name): #Quality

Action Performed:

1. Support log into a user’s account
2. Navigate to Workspaces
3. Observe the list of available workspaces

Expected Result:

Only workspaces associated with the support-logged-in user should be displayed.
The support agent’s personal workspaces should not be visible.

Actual Result:

Workspaces from both:
The user’s account and The support agent’s account are shown in the list.

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022027391412785166509
• Upwork Job ID: 2027391412785166509
• Last Price Increase: 2026-02-27

Issue Owner

Current Issue Owner: @s77rt

[melvin-bot]

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

[MelvinBot]

🔍 Issue Analysis

Proposal

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

When a support agent logs into a user's account via supportal, the Workspaces list page shows workspaces from both the support agent's own account and the target user's account. Only the target user's workspaces should be visible.

What is the root cause of that problem?

The supportal login flow in LogOutPreviousUserPage.tsx has a code path that calls signInWithSupportAuthToken() without clearing the Onyx store first.

When a support agent initiates a supportal login, LogOutPreviousUserPage checks isLoggingInAsNewUser (which compares the email in the transition URL with the current session email). If this returns false — meaning the agent already has an active session — the code at lines 42-49 calls signInWithSupportAuthToken() directly without any Onyx.clear():

if (isSupportalLogin) {
    signInWithSupportAuthToken(shortLivedAuthToken);
    // ... navigate home
    return;
}

signInWithSupportAuthToken (Session/index.ts:230-233) merely fires an API.read() call. The server response merges the target user's policies into Onyx alongside the agent's existing policies. Since WorkspacesListPage reads all policies from ONYXKEYS.COLLECTION.POLICY and filters via shouldShowPolicy() — which only checks policy.role (a server-set field still populated from the agent's prior session) — both sets of policies pass the filter and are displayed.

By contrast, the delegate (copilot) connect flow in Delegate.ts (lines 192-203) correctly calls Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) before calling openApp(), which wipes the policy collection. The same pattern exists in LogInWithShortLivedAuthTokenPage.tsx (lines 32-39), which also calls signInWithSupportAuthToken() without clearing Onyx.

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

Add an Onyx.clear() step before calling signInWithSupportAuthToken() in the supportal login path, similar to how the delegate connect flow handles it. Specifically:

1. In LogOutPreviousUserPage.tsx (lines 42-49): Before calling signInWithSupportAuthToken(), call Onyx.clear() with a preserve list similar to KEYS_TO_PRESERVE_SUPPORTAL (already defined in Session/index.ts at line 302), then call signInWithSupportAuthToken() after the clear completes.

2. Apply the same fix in LogInWithShortLivedAuthTokenPage.tsx (lines 32-39) for the same supportal code path.

This mirrors the pattern used successfully in the delegate connect flow and ensures stale policy data from the agent's session is removed before the target user's data is loaded.

What alternative solutions did you explore? (Optional)

• Client-side filtering in WorkspacesListPage: Adding delegate/support-aware filtering to shouldShowPolicy() was considered, but this is a band-aid — the real issue is stale data in Onyx from a prior session, which could cause other problems beyond just the workspace list.
• Server-side fix: Having the server return explicit null values for policies that don't belong to the target user. This would work but is less reliable than clearing client-side state, and the client should handle the transition cleanly regardless.

Detailed Investigation

Root Cause Analysis

The data flow for the bug:

1. Support agent is logged into NewDot — their policies are loaded into ONYXKEYS.COLLECTION.POLICY in Onyx
2. Agent navigates to supportal target user, which routes through LogOutPreviousUserPage with authTokenType=CONST.AUTH_TOKEN_TYPES.SUPPORT
3. isLoggingInAsNewUser checks if the transition URL email matches the session email. If it doesn't match (different user), the first path clears Onyx correctly. But if it does match (or fails to detect the difference), the second path runs.
4. signInWithSupportAuthToken() fires an API read without clearing Onyx
5. Server returns the target user's policies, which get merged into Onyx alongside the agent's existing policies
6. WorkspacesListPage reads ALL policies, filters via shouldShowPolicy → getPolicyRole, which returns truthy for both sets (the agent's old policies still have policy.role set from the prior session)
7. Both sets of workspaces are displayed

Evidence Chain

• WorkspacesListPage.tsx:140 — reads all policies from Onyx with no session scoping
• PolicyUtils.ts:399-407 — shouldShowPolicy has no delegate/support awareness
• PolicyUtils.ts:376-386 — getPolicyRole checks policy.role (a stale server-set value) first
• LogOutPreviousUserPage.tsx:42-49 — calls signInWithSupportAuthToken without Onyx.clear()
• LogInWithShortLivedAuthTokenPage.tsx:32-39 — same pattern, no Onyx clear
• Session/index.ts:230-233 — signInWithSupportAuthToken only fires API.read, no Onyx clear
• Delegate.ts:192-203 — delegate connect flow correctly calls Onyx.clear() before openApp() (the correct pattern)

Relevant Code

• src/pages/LogOutPreviousUserPage.tsx:42-49 - Supportal path that skips Onyx.clear()
• src/pages/LogInWithShortLivedAuthTokenPage.tsx:32-39 - Same missing Onyx.clear()
• src/libs/actions/Session/index.ts:230-233 - signInWithSupportAuthToken has no clearing
• src/libs/actions/Session/index.ts:302-322 - KEYS_TO_PRESERVE_SUPPORTAL already defined
• src/libs/actions/Delegate.ts:192-203 - Delegate flow showing the correct pattern
• src/pages/workspace/WorkspacesListPage.tsx:140,514-517 - Policy display logic
• src/libs/PolicyUtils.ts:376-407 - Policy filtering functions

Implementation Notes

• KEYS_TO_PRESERVE_SUPPORTAL is already defined in Session/index.ts and should be reused for the Onyx.clear() call
• The signInWithSupportAuthToken call should be chained after the Onyx.clear() promise resolves to avoid race conditions
• Need to verify the fix doesn't break the HybridApp transition path (setupNewDotAfterTransitionFromOldDot in Session/index.ts)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[mukhrr]

Proposal

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

When a support agent uses supportal to log into a user's account and navigates to the Workspaces page, workspaces from both the support agent's own account and the target user's account are displayed, instead of showing only the target user's workspaces.

What is the root cause of that problem?

The root cause is in LogOutPreviousUserPage, which handles transitions from OldDot to NewDot. When a supportal login is initiated, the transition URL may contain the support agent's own email (since the redirect originates from the agent's OldDot session). The isLoggingInAsNewUser check in SessionUtils compares the email parameter from the transition URL against the current session email. When these match (both are the support agent's email), it returns false, causing the code to skip signOutAndRedirectToSignIn and call signInWithSupportAuthToken directly without clearing existing Onyx data first.

App/src/pages/LogOutPreviousUserPage.tsx

Lines 36 to 49 in 3880251

	if (isLoggingInAsNewUser) {
	// We don't want to close react-native app in this particular case.
	signOutAndRedirectToSignIn(false, isSupportalLogin);
	return;
	}
	if (isSupportalLogin) {
	signInWithSupportAuthToken(shortLivedAuthToken);
	Navigation.isNavigationReady().then(() => {
	// We must call goBack() to remove the /transition route from history
	Navigation.goBack();
	Navigation.navigate(ROUTES.HOME);
	});
	return;

The signInWithSupportAuthToken function only makes an API.read call, which merges the target user's policy data into Onyx alongside the support agent's existing policies. Since shouldShowPolicy checks policy.role (which was set by the backend for each policy during the agent's original session), the agent's old policies still pass the filter and appear in the workspace list.

App/src/libs/actions/Session/index.ts

Lines 230 to 233 in 3880251

	function signInWithSupportAuthToken(authToken: string) {
	const {optimisticData, finallyData} = getShortLivedLoginParams(true);
	API.read(READ_COMMANDS.SIGN_IN_WITH_SUPPORT_AUTH_TOKEN, {authToken}, {optimisticData, finallyData});
	}

Specifically, in isLoggingInAsNewUser, when paramsEmail === sessionEmail (both are the agent's email), it short-circuits and returns false:

App/src/libs/SessionUtils.ts

Lines 10 to 28 in 3880251

	function isLoggingInAsNewUser(transitionURL?: string, sessionEmail?: string): boolean {
	// The OldDot mobile app does not URL encode the parameters, but OldDot web
	// does. We don't want to deploy OldDot mobile again, so as a work around we
	// compare the session email to both the decoded and raw email from the transition link.
	const params = new URLSearchParams(transitionURL);
	const paramsEmail = params.get('email');
	// If the email param matches what is stored in the session then we are
	// definitely not logging in as a new user
	if (paramsEmail === sessionEmail) {
	return false;
	}
	// If they do not match it might be due to encoding, so check the raw value
	// Capture the un-encoded text in the email param
	const emailParamRegex = /[?&]email=([^&]*)/g;
	const matches = emailParamRegex.exec(transitionURL ?? '');
	const linkedEmail = matches?.[1] ?? null;
	return linkedEmail !== sessionEmail;

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

1. In LogOutPreviousUserPage.tsx, treat supportal login as always requiring a full session clear, regardless of the isLoggingInAsNewUser check. A supportal login inherently means accessing a different user's account context, so old Onyx data should always be cleared.
   

   App/src/pages/LogOutPreviousUserPage.tsx

   Lines 36 to 49 in 3880251

   	if (isLoggingInAsNewUser) {
   	// We don't want to close react-native app in this particular case.
   	signOutAndRedirectToSignIn(false, isSupportalLogin);
   	return;
   	}
   	if (isSupportalLogin) {
   	signInWithSupportAuthToken(shortLivedAuthToken);
   	Navigation.isNavigationReady().then(() => {
   	// We must call goBack() to remove the /transition route from history
   	Navigation.goBack();
   	Navigation.navigate(ROUTES.HOME);
   	});
   	return;

--- a/src/pages/LogOutPreviousUserPage.tsx
+++ b/src/pages/LogOutPreviousUserPage.tsx
@@ -33,14 +33,10 @@
         const isLoggingInAsNewUser = isLoggingInAsNewUserSessionUtils(transitionURL ?? undefined, sessionEmail);
         const isSupportalLogin = authTokenType === CONST.AUTH_TOKEN_TYPES.SUPPORT;

-        if (isLoggingInAsNewUser) {
+        if (isLoggingInAsNewUser || isSupportalLogin) {
             // We don't want to close react-native app in this particular case.
             signOutAndRedirectToSignIn(false, isSupportalLogin);
             return;
         }
-
-        if (isSupportalLogin) {
-            signInWithSupportAuthToken(shortLivedAuthToken);
-            Navigation.isNavigationReady().then(() => {
-                // We must call goBack() to remove the /transition route from history
-                Navigation.goBack();
-                Navigation.navigate(ROUTES.HOME);
-            });
-            return;
-        }

         // Even if the user was already authenticated in NewDot, we need to reauthenticate them with shortLivedAuthToken,

When signOutAndRedirectToSignIn is called with shouldStashSession=true, it clears Onyx via redirectToSignIn() and stashes the support agent's session for later restoration. After the Onyx clear, the auth token is removed, causing the app to switch to public screens. The transition URL (with authTokenType=support and shortLivedAuthToken) is preserved in the browser URL, so LogInWithShortLivedAuthTokenPage picks it up and calls signInWithSupportAuthToken on a clean Onyx store, ensuring only the target user's policies are loaded.

[abbasifaizan70]

Proposal

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

Support log into a user account and navigate to Workspaces.
Workspaces from both the support-logged-in user and the support agent are displayed.

What is the root cause of that problem?

WorkspacesListPage builds the workspace list from all policy_* entries and gates visibility with shouldShowPolicy(policy, true, session?.email), but this check is not strict enough for support sessions.

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 514 to 516 in e6d82ef

	for (const policy of Object.values(policies)) {
	if (!policy || !shouldShowPolicy(policy, true, session?.email)) {
	continue;

getPolicyRole() returns policy.role first when present, so shouldShowPolicy() can pass for stale policies from the support agent session even when they are unrelated to the currently support-logged-in account.

App/src/libs/PolicyUtils.ts

Lines 376 to 386 in e6d82ef

	function getPolicyRole(policy: OnyxInputOrEntry<Policy>, currentUserLogin?: string, shouldCheckGlobalPolicyRole = true): string | undefined {
	if (shouldCheckGlobalPolicyRole && policy?.role) {
	return policy.role;
	}
	if (!currentUserLogin) {
	return;
	}
	return policy?.employeeList?.[currentUserLogin]?.role;
	}

App/src/libs/PolicyUtils.ts

Lines 399 to 406 in e6d82ef

	function shouldShowPolicy(policy: OnyxEntry<Policy>, shouldShowPendingDeletePolicy: boolean, currentUserLogin: string | undefined): boolean {
	return (
	!!policy?.isJoinRequestPending ||
	(!!policy &&
	policy?.type !== CONST.POLICY.TYPE.PERSONAL &&
	(shouldShowPendingDeletePolicy || policy?.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE || Object.keys(policy.errors ?? {}).length > 0) &&
	!!getPolicyRole(policy, currentUserLogin))
	);

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

diff --git a/src/pages/workspace/WorkspacesListPage.tsx b/src/pages/workspace/WorkspacesListPage.tsx
@@
 function WorkspacesListPage() {
@@
     const [session] = useOnyx(ONYXKEYS.SESSION);
@@
+    const currentUserLogin = currentUserPersonalDetails.login ?? session?.email;
+    const isSupportSession = session?.authTokenType === CONST.AUTH_TOKEN_TYPES.SUPPORT;
+
+    const shouldIncludePolicyInWorkspaceList = (policy: PolicyType) => {
+        if (!shouldShowPolicy(policy, true, currentUserLogin)) {
+            return false;
+        }
+
+        // In support sessions, enforce explicit membership/ownership for the acted-on account
+        // so stale support-agent policies are never rendered in the workspace list.
+        if (!isSupportSession) {
+            return true;
+        }
+
+        const login = currentUserPersonalDetails.login ?? currentUserLogin;
+        const accountID = currentUserPersonalDetails.accountID;
+
+        return !!(
+            (login && (policy.owner === login || policy.employeeList?.[login])) ||
+            (accountID && policy.ownerAccountID === accountID)
+        );
+    };
@@
         for (const policy of Object.values(policies)) {
-            if (!policy || !shouldShowPolicy(policy, true, session?.email)) {
+            if (!policy || !shouldIncludePolicyInWorkspaceList(policy)) {
                 continue;
             }

diff --git a/tests/ui/WorkspaceListPageTest.tsx b/tests/ui/WorkspaceListPageTest.tsx
@@
 describe('WorkspaceListPage', () => {
@@
+    it('should only show support-logged-in user workspaces during support session', async () => {
+        const SUPPORT_EMAIL = 'support@expensify.com';
+        const USER_EMAIL = 'customer@example.com';
+        const USER_ACCOUNT_ID = 111;
+
+        await Onyx.set(`${ONYXKEYS.SESSION}`, {
+            email: SUPPORT_EMAIL,
+            accountID: USER_ACCOUNT_ID,
+            authTokenType: 'support',
+        });
+
+        await Onyx.set(ONYXKEYS.PERSONAL_DETAILS_LIST, {
+            [USER_ACCOUNT_ID]: {
+                login: USER_EMAIL,
+                accountID: USER_ACCOUNT_ID,
+                displayName: USER_EMAIL,
+            },
+        });
+
+        await Onyx.set(`${ONYXKEYS.COLLECTION.POLICY}USER_POLICY`, {
+            id: 'USER_POLICY',
+            name: 'Customer Workspace',
+            role: 'admin',
+            owner: USER_EMAIL,
+            ownerAccountID: USER_ACCOUNT_ID,
+            employeeList: {
+                [USER_EMAIL]: {role: 'admin'},
+            },
+        });
+
+        await Onyx.set(`${ONYXKEYS.COLLECTION.POLICY}SUPPORT_POLICY`, {
+            id: 'SUPPORT_POLICY',
+            name: 'Support Workspace',
+            role: 'admin',
+            owner: SUPPORT_EMAIL,
+            ownerAccountID: 999,
+            employeeList: {
+                [SUPPORT_EMAIL]: {role: 'admin'},
+            },
+        });
+
+        renderPage();
+        await waitForBatchedUpdatesWithAct();
+
+        expect(screen.getByText('Customer Workspace')).toBeOnTheScreen();
+        expect(screen.queryByText('Support Workspace')).not.toBeOnTheScreen();
+    });
 });

[joekaufmanexpensify]

@thesahindia could you review proposals here?