[Due for payment 2026-06-25] Workspaces - Items on "Select Settings" remain selected when returning to RHP.

[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.3.91-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: #91241
Email or phone of affected tester (no customers): applausetester+ib0005@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Use an expensifail account.
Prerequisite: Have at least two workspaces created.

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces"
3. Click on the three dots menu on any workspace and select "Copy Settings"
4. Select any workspace and click on "Next"
5. Select some features.
6. Click on the arrow on the top left corner.
7. Click on "Next" again.
8. Note that features are not checked anymore.
9. Select some features again and click on "Next"
10. Click on the arrow on the top left corner two times to return to workspace selector.
11. Click on "Next" again.
12. Note that now, features on "Select Settings" are still selected.

Expected Result:

Features selected while on "Copy Settings" process, should not be checked anymore after reopening RHP.

Actual Result:

Features selected while on "Copy Settings" process, remain selected after returning to RHP from workspace selector.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169659_1780410974765.Set_7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7169659

Issue Owner

Current Issue Owner: @ishpaul777

[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/7b725a1744eccacede09688541e138c8cc49a958bda8aa5a689d461791f733c6

[melvin-bot]

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

[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

ℹ️ Automated root-cause analysis from MelvinBot. The mechanism is confirmed in code; the intended behavior is a product call (see the design tension below).

TL;DR: The "Select settings" checkboxes are driven by the persisted COPY_POLICY_SETTINGS.parts Onyx value. That value is only committed when you press Next on the features step, and it is never reset when you navigate back to the workspaces step and forward again. So once you've advanced past the features step once, the selection "sticks" for the rest of the in-flight flow — which is why pass 1 (steps 5–8) shows the boxes cleared but pass 2 (steps 9–12) shows them still checked.

What is the root cause of that problem?

The feature page renders its checkboxes from a value that falls back to Onyx:

• CopyPolicySettingsSelectFeaturesPage.tsx:124 — resolvedSelectedFeatures = selectedFeatures ?? copyPolicySettings?.parts ?? []. Local component state is null on every fresh mount, so the displayed selection comes from the persisted Onyx parts.

parts is written to Onyx only when the user presses Next on the features step:

• CopyPolicySettingsSelectFeaturesPage.tsx:236-242 (saveAndNavigate → setCopyPolicySettingsData({parts: ...})).

The back arrow just calls Navigation.goBack (:285) without touching Onyx, and the workspaces step's Next only writes targetPolicyIDs, never parts (CopyPolicySettingsSelectWorkspacesPage.tsx:128-134). The whole flow's Onyx state is cleared only when the flow is freshly launched from the three-dot menu (WorkspacesListPage.tsx:387-393) — not on internal back-navigation and not when the RHP is closed.

That explains the inconsistency the tester observed:

• Steps 5–8 (cleared): the user went back from the features step without pressing Next, so parts was never committed → re-entry reads [] → nothing checked.
• Steps 9–12 (still checked): the user pressed Next (reaching Confirm), so parts is now in Onyx → going back to the workspaces step and forward again re-reads the committed parts → boxes remain checked.

Design tension — why "still checked" may actually be intended

Persistence here is deliberate. PR #91241's own Test 3 ("Edit workspaces from confirm") relies on returning to the features step with the previous selection still checked (cleansed of incompatible parts) after editing the target workspaces. Step 12 in this report is the same workspaces→features transition and produces the same (intended) "still checked" result.

So strictly speaking, step 12 matches the documented design, and step 8 (cleared) is the anomaly — it only clears because the selection was never committed. The QA expected-result ("should not be checked anymore after reopening RHP") conflicts with that persistence design. The genuine user-facing defect is the inconsistency between the two passes, not the persistence itself.

Note also that the state is not reset when the RHP is dismissed via the X — it's only reset on the next launch from the three-dot menu (PR Test 4). The repro never closes/reopens the RHP; it navigates back to the first step within the same flow.

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

First decide the intended behavior, since the two options pull in opposite directions:

1. Keep persistence, make it consistent (recommended, lower risk): commit the in-progress selection to Onyx when leaving the features step via the back arrow too (set parts in an onBackButtonPress handler in CopyPolicySettingsSelectFeaturesPage.tsx, mirroring saveAndNavigate). Then steps 5–8 also keep the selection, removing the inconsistency, and Test 3 keeps working.

2. Match the QA expected-result (reset on return): clear parts (or local selection) when the features step is re-entered from the workspaces step. ⚠️ This contradicts PR [Bulk workspace edits] Add Copy Policy Settings Double-check confirmation page (step 3 of 3) #91241's intentional persistence and would break Test 3's "edit workspaces from confirm" flow, so it should not be done without product sign-off.

I recommend Option 1 — it aligns with the feature's documented design and only removes the surprising "sometimes cleared, sometimes not" behavior.

What alternative solutions did you explore? (Optional)

Clearing COPY_POLICY_SETTINGS on RHP dismiss (rather than only on three-dot-menu launch) was considered, but it doesn't address the in-flow inconsistency in this repro (the RHP is never closed) and would change the documented Test 4 behavior.

---

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

[lakchote]

#91241 is behind a beta and it's a minor UI bug, so demoting