main ← fix-staff-enable-when-everyone-excluded
merged 06:34PM - 01 Jul 26 UTC
Fixes a bug reported at https://meta.discourse.org/t/issue-with-enabling-upcomin…g-changes/395881/31
### What
When an upcoming change's `allow_enabled_for` excludes `everyone` (for example `[staff, specific_groups]`, as the former `reporting_improvements` change had), selecting **Staff** in the *Enabled for* dropdown failed with a `422` and the selection snapped back to *No one*.
### Why
`enabledForChanged` toggled the setting on **before** persisting the staff group. On the server, `UpcomingChanges::Toggle#allowed_enabled_for_target` treats "enabled with no group configured" as targeting `everyone` — which these changes disallow — so the toggle was rejected and the change was never enabled.
Changes that allow `everyone` (the common case) weren't affected, because the initial toggle passes the policy and the staff group is saved a moment later.
### Fix
Persist the staff group **before** toggling, mirroring the existing "specific groups" path (which already saves groups first and only then enables the change). By the time the setting is toggled on, it is already scoped to staff, so the policy passes.
### Tests
- **Component** (`upcoming-change-item-test.gjs`): asserts the request order is `groups` → `toggle` for the staff selection on an `everyone`-excluded change, and that everyone/no-one still toggle first then clear groups.
- **System** (`admin_upcoming_changes_spec.rb`): enabling for staff on an `everyone`-excluded change now succeeds and persists the staff `SiteSettingGroup`.
### Screenshots
Before / after — selecting **Staff** on an `everyone`-excluded change (Horizon, light, desktop):
<img width="1664" height="466" alt="reporting-improvements-before-after" src="https://github.com/user-attachments/assets/085d9e7d-f61b-47bc-a683-5792e72a7217" />