What
List accounts, add an account, remove an account. No roles, no organisations,
no email invitations.
Why
This is the only gap on the list that actually blocks usage rather than
inconveniencing it: a team today shares one admin password. That also quietly
breaks the audit log, which records the same email address for every action no
matter who performed it.
How
apps/auth/src/server.ts:44 hard-closes sign-up/email once the first
account exists. Do not reopen public sign-up. Add a route in the auth service
that creates an account, callable only by the manager with an admin session.
- List and delete on the manager side against
auth.db, which
manager/internal/auth/auth.go:90 already reads.
- New page
apps/web/src/routes/system.settings.users.tsx, structurally a clone
of system.settings.tokens.tsx.
- Update
docs/security.md.
Deliberately without RBAC
Every account is an admin. Roles land when somebody actually asks for
read-only access, and then it is one column, not a permission matrix.
What
List accounts, add an account, remove an account. No roles, no organisations,
no email invitations.
Why
This is the only gap on the list that actually blocks usage rather than
inconveniencing it: a team today shares one admin password. That also quietly
breaks the audit log, which records the same email address for every action no
matter who performed it.
How
apps/auth/src/server.ts:44hard-closessign-up/emailonce the firstaccount exists. Do not reopen public sign-up. Add a route in the auth service
that creates an account, callable only by the manager with an admin session.
auth.db, whichmanager/internal/auth/auth.go:90already reads.apps/web/src/routes/system.settings.users.tsx, structurally a cloneof
system.settings.tokens.tsx.docs/security.md.Deliberately without RBAC
Every account is an admin. Roles land when somebody actually asks for
read-only access, and then it is one column, not a permission matrix.