[$250] Workspace - Not here page appear after toggle of keep me as admin and create WS

[jponikarchuk]

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: v9.3.28-1
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: #81008
Email or phone of affected tester (no customers): applausetester+vq+0303@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Workspace Settings

Action Performed:

Precondition: Set an Expensifail account as an approved accountant (isApprovedAccountant: true). Enter in the Console: await Onyx. merge('account', {
isApprovedAccountant: true,
})

1. Open the Expensify app.
2. Go to Workspaces and click “New workspace.”
3. Select another account as Owner and toggle off the “Keep me as an admin” option
4. Go to the member page of the newly created Workspace

Expected Result:

The member page opens normally

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

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028734938544918548
• Upwork Job ID: 2028734938544918548
• Last Price Increase: 2026-03-03

Issue Owner

Current Issue Owner: @allgandalf

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #81008 - "Add the ability to create a workspace for a client" by @huult (High confidence)
Related Issues: #80057

Recommendation: REVERT

The PR contains a critical bug in the workspace creation flow that causes access control issues when creating a workspace with a different owner.

Labels: This issue has DeployBlockerCash label. Since this is a Frontend bug caused by an App PR, this label should be kept. The issue is reproducible on staging and is N/A for production (new feature), which is consistent with keeping the DeployBlockerCash label.

📋 Detailed Analysis

Evidence

The bug report states:

1. Set account as approved accountant (isApprovedAccountant: true)
2. Create new workspace and select another account as Owner
3. Toggle OFF "Keep me as an admin"
4. Navigate to member page → "Not here page" appears

PR #81008 added the feature to create workspaces for clients (with different owners), which is exactly the flow described in the bug report. Melvin-bot correctly identified this PR as the cause.

Verification

I verified that PR #81008 modifies the following critical files related to workspace creation:

• src/libs/actions/Policy/Policy.ts - Core workspace creation logic
• src/pages/workspace/WorkspaceConfirmationPage.tsx - Workspace creation flow
• src/components/WorkspaceConfirmationForm.tsx - Form handling
• src/pages/workspace/WorkspaceConfirmationOwnerSelectorPage.tsx - New owner selector page

The PR adds the makeMeAdmin parameter and owner selection functionality, which are directly related to the bug reproduction steps.

Root Cause

The bug is in src/libs/actions/Policy/Policy.ts in the createDraftInitialWorkspace function (line 2260):

value: {
    id: policyID,
    type: type || CONST.POLICY.TYPE.TEAM,
    name: workspaceName,
    role: CONST.POLICY.ROLE.ADMIN,  // ← BUG: Always ADMIN, ignores makeMeAdmin
    owner: deprecatedSessionEmail,
    // ...
}

The function always sets role: CONST.POLICY.ROLE.ADMIN in the policy draft, regardless of the makeMeAdmin parameter value.

What should happen:

• When makeMeAdmin=false, the current user should have role: CONST.POLICY.ROLE.USER
• When makeMeAdmin=true, the current user should have role: CONST.POLICY.ROLE.ADMIN

What actually happens:

• The draft policy always has role: ADMIN for the current user
• But in the actual workspace creation (buildPolicyData), the employeeList correctly assigns USER role when makeMeAdmin=false
• This mismatch causes the access control logic in WorkspacePageWithSections.tsx to deny access
• The "Not here page" is shown because the system thinks the user doesn't have permission to view the members page

The WorkspacePageWithSections component checks isPolicyAdmin(policy) to determine if the user can access admin-only pages. With the draft role set incorrectly, this check fails for users who toggled off "Keep me as an admin", blocking them from accessing workspace pages they should be able to view.