[Due for payment 2026-06-25] Workspace - Editor role is not role dropdown when the invited member is an editor

[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: #90995
Email or phone of affected tester (no customers): applausetester+sdjoisjosd1@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:

Precondition:

• Log in with Expensifail account.
• Create a Submit workspace on OD.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Members.
3. Invite a member.
4. Click All members dropdown.

Expected Result:

Editor role will be in the role dropdown because the invited member is an editor.

Actual Result:

Editor role is not role dropdown when the invited member is an editor.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172952_1780688070013.18.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @abzokhattab

[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/93b1e684c7d1942ba082a0fab8fc06ed3bfa6d4e6435003b55f326b1f5905506

[melvin-bot]

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

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

PR #90995 added the new EDITOR role for Submit workspaces, but the role filter dropdown on the Members page (the "All members" dropdown) was never updated to include it.

The dropdown options are hardcoded to All members / Admins / Approvers (plus Auditors only for Control policies):

WorkspaceMembersPage.tsx:564-575

There is no EDITORS entry in WORKSPACE_MEMBER_FILTER_VALUES, no Editor case in rolePreFilter, and no editors translation key in en.ts:6269-6272. So on a Submit workspace where the default member role is editor, the Editor role can never appear as a filter option.

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

In WorkspaceMembersPage.tsx:

1. Add EDITORS: 'editors' to WORKSPACE_MEMBER_FILTER_VALUES.
2. Conditionally push an "Editors" option onto roleFilterOptions when the policy is a Submit workspace, using the existing isSubmitPolicy(policy) helper from PolicyUtils.ts:1051 (mirroring how the Auditors option is gated behind isControlPolicy).
3. Add a case in rolePreFilter for the new value: return employee?.role === CONST.POLICY.ROLE.EDITOR;.
4. Add an editors translation key (e.g. editors: 'Editors') under workspace.people in all src/languages/*.ts files.

Why Submit-gated rather than always shown

The editor role only exists on Submit workspaces (isPolicyEditor / role assignment is gated by isSubmitPolicy), so the filter option should appear only for Submit workspaces — consistent with the Auditors filter being shown only for Control policies.

What alternative solutions did you explore? (Optional)

None — the gap is a missing dropdown option that directly mirrors the existing Admins/Approvers/Auditors pattern.

Note: This is a frontend-only change scoped entirely to the Expensify/App repo.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[godzillaxbox19982014-lgtm]

Proposal

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

Workspace - Editor role is not role dropdown when the invited member is an editor

What is the root cause of that problem?

I traced this to the path that handles workspace name:

• src/pages/workspace/WorkspaceMembersPage.tsx:163 (isPolicyAdmin): const isPolicyAdmin = canEditWorkspaceSettings(policy);
• src/pages/workspace/WorkspaceMembersPage.tsx:675 (roleFilterDropdown): const roleFilterDropdown = shouldShowRoleFilter ? (
• src/pages/workspace/WorkspaceMembersPage.tsx:863 (matching code path): const menuItems: Array<DropdownOption<ValueOf<typeof CONST.POLICY.SECONDARY_ACTIONS>>> = [
• The local evidence matches this recurring failure shape: shared workspace list builds options without the same eligibility filter as another workspace surface. Here, src/pages/workspace/WorkspaceMembersPage.tsx:163 and src/pages/workspace/WorkspaceMembersPage.tsx:675 do not agree on the same workspace name 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/WorkspaceMembersPage.tsx:163 to derive workspace name from the workspace setup and policy state that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/WorkspaceMembersPage.tsx:675; that follows the safer family move to move the rule into the shared selector/helper, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Workspace, Policy, Categories, Tags, Rules surface and avoid changing account/admin permission surfaces, policy owner/current-user exceptions.

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/unit/Policy*.ts for the exact issue flow: Workspace - Editor role is not role dropdown when the invited member is an editor.
2. Cover the counter-case near src/pages/workspace/WorkspaceMembersPage.tsx:163 so valid existing workspace name 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 consistent at the first read/write boundary shown above.

[hungvu193]

Let's demote it. It's gated behind submit workspace