User Management

Where users are managed#

Settings → Users lists every account with its username, email, roles, status (active / inactive, plus a must reset badge when a password change is pending), and creation date. All user administration is admin-only; the one exception is that any signed-in user may change their own email through the same API.

Global roles are admin, editor, and viewer, and a user can hold more than one. What each role can do — including how global roles interact with per-project roles on the pipelines surface — is covered in Roles and permissions.

Creating a user#

1. Open Settings → Users and select New user.
2. Fill in:
   • Username — the login name, shown in the audit log.
   • Email.
   • Initial password — minimum 8 characters. Treat it as temporary.
   • Roles — one or more of admin / editor / viewer (default: viewer).
3. Select Create.

Users created through the UI are always flagged for a forced password change: on their first sign-in they must set a new password before they can reach any other page. Share the initial password over a channel you trust and let the forced change take it out of circulation.

Note. Users provisioned by an SSO or LDAP provider are created automatically on first login and carry an identity-provider subject; their roles come from the provider's role mapping. See Authentication providers.

Editing a user#

Edit on a user's row lets an admin change:

• Email
• Roles
• Active — the same flag the Deactivate action clears; ticking it here re-enables a disabled account.

Resetting a password#

Reset password on a user's row asks for a new password (minimum 8 characters) and flags the account must_change_password — the user is forced to choose their own password at the next login, so the value the admin typed is again only temporary.

Disabling a user#

Deactivate on a user's row disables sign-in. The dialog requires typing the username to confirm. Key semantics:

• The account is disabled, not deleted — history and audit attribution are preserved, and an admin can re-enable it later via Edit → Active.
• Sessions end immediately. Every authenticated request re-loads the user and checks the active flag, so an existing browser session or bearer token is rejected with 401 on its very next request — there is no grace window until token expiry.
• API tokens stop working immediately for the same reason: a token only resolves when its owning user is active. See API tokens.
• You cannot deactivate your own account — the API refuses it, so a deployment can't lock out its last working admin by accident.

Tip. If you only need to kill a leaked credential rather than the whole account, revoke the specific API token or reset the password instead of deactivating the user.

Audit trail#

User creation, updates, password resets, and deactivations are all recorded in the audit log with the acting admin, the affected user, and a before/after snapshot (passwords are redacted). See Audit.