Accounts & access

Reading a meet is public; changing one requires an account. Access is controlled by accounts and role grants.

Creating accounts

• The first admin is created with the user-admin CLI (see Install & first run).
• After that, admins invite users from the app: minting an invite link (and emailing it, if email is configured). The invitee clicks the link and sets their own password.
• A new account has no privileges until you grant it a role — creating the user and granting a role are two steps on the users screen.
• Password reset is the same invite link: re-mint it for an existing user and they set a new password. There is no self-serve “forgot password” — an admin has to send the link.
• Admins can disable an account or revoke its sessions.

Roles and scope

Access is a role granted at a scope — site, league, team, or meet. A team admin manages their team’s roster, entries, and the meets their team swims in; a league admin manages the league; clerk/desk-style roles cover run-day work. See Roles & permissions for the full matrix and how to grant roles.

Account administration is itself scoped — an admin can only manage accounts and grant roles within the part of the org they’re responsible for. Nobody can escalate beyond their own delegable subtree (e.g. a team-level admin can’t reset a site admin’s password).

How auth works

Sign-in sets a secure session cookie; write endpoints require it. An expired session surfaces in the app as a prompt to sign in again. Mutating writes are additionally guarded by optimistic locking so two people editing the same thing can’t clobber each other silently.