You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(auth): propagate invite role to users.role + recognise FO-1b admin taxonomy (#253)
Multi-layer mismatch was silently 403'ing freshly-bootstrapped founders
on every admin-gated route. Trace:
1. INSERT_USER / SELECT_USER_BY_USERNAME didn't touch the users.role
column. New rows got the DB default ('user'); reads dropped the
column entirely, so /auth/me always reported "role": "user" even
when the row was correct.
2. ensure_user (the claim helper) didn't forward the invite role
to store.create_user. Even with the storage layer fixed, the
founder bootstrap path stamped role='user' for every claimer.
3. require_admin matched only the legacy role string 'admin'. The
FO-1b invite taxonomy uses 'enterprise_admin' / 'l2_admin' /
'user' — so a correctly-rolled enterprise_admin user still 403'd
on every admin route.
Fix: thread role through INSERT_USER + SELECT_USER_BY_USERNAME +
store.create_user + ensure_user + claim_invite_route. Centralise the
admin-equivalence check in auth.is_admin_role() and use it in
require_admin plus the five existing `role == "admin"` sites in
crosstalk_routes + activity_routes so the legacy and new
taxonomies stay in sync.
New test: test_claim_persists_invite_role — invites a user with
role=enterprise_admin, claims it, asserts /auth/me reports the
correct role. Prevents the regression that produced this bug.
0 commit comments