Follow-up to the Google OAuth slice (docs/adr/0028): this release's OAuth is link-only — an already-authenticated admin links their own Google account, and an unrecognized Google sub is always rejected, never auto-provisioned into a new user.
Once spoolbook is exposed publicly (see docs/adr/0027's "eventual public release" framing) and multi-user (#91) exists, a stranger clicking "Sign in with Google" needs a real answer. User's stated preference: "an admin should be able to manage subs. either they can't register if they don't have an invite, or they can register but no access. I kind of want the invite route."
So: an invite mechanism (admin generates an invite — link or code — for a specific email or open-ended, invitee signs in with Google and it provisions a real user scoped by that invite) rather than open self-registration.
Blocked by #91 (needs the role model to exist first — an invited user has to land somewhere with defined permissions).
Follow-up to the Google OAuth slice (docs/adr/0028): this release's OAuth is link-only — an already-authenticated admin links their own Google account, and an unrecognized Google sub is always rejected, never auto-provisioned into a new user.
Once spoolbook is exposed publicly (see docs/adr/0027's "eventual public release" framing) and multi-user (#91) exists, a stranger clicking "Sign in with Google" needs a real answer. User's stated preference: "an admin should be able to manage subs. either they can't register if they don't have an invite, or they can register but no access. I kind of want the invite route."
So: an invite mechanism (admin generates an invite — link or code — for a specific email or open-ended, invitee signs in with Google and it provisions a real user scoped by that invite) rather than open self-registration.
Blocked by #91 (needs the role model to exist first — an invited user has to land somewhere with defined permissions).