[Due for payment 2026-07-13] [Submit] Workspace - Editor role filter persists after upgrading workspace to Collect

[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.14-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: #93022
Email or phone of affected tester (no customers): applausetester+sdodjsodddds@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. Click on the role dropdown.
4. Select Editor.
5. Click Invite member.
6. Select a member > Next.
7. On confirm page, click Role.
8. Click Upgrade > Got it, thanks.
9. Click Invite or close the RHP.
10. Click on the role dropdown.

Expected Result:

Role filter should reset to All after upgrading workspace to Collect because Editor role is no longer available.

Actual Result:

Editor role filter persists after upgrading workspace to Collect.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7184613_1781786205875.2.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @hungvu193

[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/57b393d10acedd3a3a5ac729411d4b2a6f026934d6a930324d34ee58565e97a9

[melvin-bot]

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

[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 role filter selection is stored in component state (selectedRoleFilter) and is only ever reset by an explicit user action in handleRoleFilterChange. Nothing resets it when the set of available role options changes.

The "Editors" option only exists for Submit workspaces — it is conditionally pushed onto roleFilterOptions behind isSubmitPolicy(policy). When the workspace is upgraded to Collect, isSubmitPolicy(policy) becomes false, so "Editors" is no longer rendered in the dropdown. But the stale selectedRoleFilter still holds the editors value, so:

• the dropdown label keeps showing "Editors" (selectedRoleFilter?.text), and
• rolePreFilter keeps filtering by CONST.POLICY.ROLE.EDITOR (WorkspaceMembersPage.tsx:626-627).

This was introduced in #93022, which added the Submit-only "Editors" filter. The same class of bug also applies to the other conditional options (cardAdmins/auditors for Control policies) if a workspace is downgraded while one of those filters is active.

Supporting evidence

• State is held here with no policy-driven reset: selectedRoleFilter useState.
• The only place it is cleared is the manual dropdown onChange handler: handleRoleFilterChange.
• "Editors" option is conditional on isSubmitPolicy(policy): WorkspaceMembersPage.tsx:592-597.

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

When the currently-selected role filter is no longer present in roleFilterOptions, reset it back to "All". Add an effect in WorkspaceMembersPage that watches roleFilterOptions (or the policy type) and, if selectedRoleFilter is set but its value is not found in the current options, calls setSelectedRoleFilter(null).

This is a generic fix (keyed off "is the selected value still a valid option?") so it also covers downgrades that remove cardAdmins/auditors, not just the Editor → Collect case.

What alternative solutions did you explore? (Optional)

Resetting strictly on policy.type change would also work, but checking membership against the live roleFilterOptions is more robust and self-maintaining if new conditional roles are added later.

---

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

[hungvu193]

I already mentioned it here

#93022 (comment)

Not a blocker btw. Let me know if we want to fix this

[iwiznia]

Yeah @hungvu193 let's fix it