- Shipped
- August 29, 2026 at 7:06 AM UTC
- Author
- Kamo
- Commit
- 9ae5fe3
The button asked for organization ownership AND CONFIGURE_SYSTEM. The System Member is provisioned as an Administrator in every organization — all 34 of its member rows carry the full right set — but it is never flagged as an owner, so the AND hid the wizard from exactly the operator most likely to be finishing somebody's setup for them. The button was alone in that. /settings/wizard guards on CONFIGURE_SYSTEM, and the API behind it admits CONFIGURE_SYSTEM or ownership; both have admitted the System Member all along. So this is the button catching up with what it links to, not a widening of access — nobody can reach anything they could not reach by typing the URL. The rule moved into orgSetupWizard.ts as canOfferGettingStarted and is covered there, including the two conditions that are easy to lose: CONFIGURE_SYSTEM is still required either way, because the wizard writes settings gated on it and a button leading straight to a redirect is not a button; and nothing is decided until the session AND the server's latch have both arrived, or the button flashes on and off on every page load. Identifying the System Member is the one soft spot, and it is deliberate. The session carries no is_system_user flag — adding one means a 33rd positional argument through createSession and every caller — so isSystemMemberSession reads the username sentinel, which the backfill service leaves as the only signal: none of those 34 member rows has a username_alias, so the session's alias is always "__system__". It is an affordance check, not an authorization one; being wrong shows or hides a button and cannot grant anything.