Users

The user management panel is where admins do day-to-day identity work: onboarding new users, resetting forgotten passwords, helping someone who's lost their MFA device. It's also where group memberships are assigned, which is what actually gives a user permission to do anything in Fabrik.

The list view

Settings → Administration → Users opens a paginated list of every user — local and LDAP-mirrored — with search and filters:

• Search over username, email, first name, last name.
• Group filter — only show users in a specific group (e.g. only Admins).
• Active filter — show active or deactivated users.
• Permission filter — show users who hold a specific Django permission, either directly or via a group.

Page size defaults to 100 and can be raised to 1,000 for bulk audits.

Each row shows username, email, group memberships as badges, the active flag, and last-login timestamp. Click a row to open the detail drawer.

Creating a user

Admin-created users get a username, email, password, and optional group memberships. The first group membership is what gives the user any real capability — a user in no groups has no permissions, which is rarely what you want.

Email verification is separate from account creation — a new user isn't considered email-verified until either they click the verification link (if email is configured) or an admin verifies them manually. See Verifying email manually below.

Editing a user

The edit form updates any of:

• Email, first name, last name.
• Active flag (equivalent to the activate/deactivate actions below — just a different entry point).
• Staff flag (grants access to the Django admin — rarely needed, most admin work happens in the Fabrik UI).
• Group memberships.

The backend snapshots the pre-edit state before saving so audit logs can show exactly what changed; the UI can display a diff if you need to verify before confirming.

Activating and deactivating

Two dedicated actions: Activate flips is_active on, Deactivate flips it off. A deactivated user:

• Cannot log in (the auth backend rejects inactive users).
• Is hidden from most pickers (query share targets, escalation recipients).
• Keeps their data. Saved queries, scheduled tasks, snapshots — everything stays.

Deactivate rather than delete for anyone who might return or whose data you might need to reference. Delete only for truly gone-forever accounts.

Password resets

Two paths depending on whether email is working:

Reset password directly

If you know the new password (user called you, gave you a temporary string to set), use Reset password and enter the new value. The user can log in with it immediately and change it themselves from their profile.

Generate a one-time reset code

When email is broken or the user is off-channel (remote site with no SMTP relay, lost account access entirely), use Generate reset code instead:

The code is stored hashed in the database (same hashing as a password) — even a direct database reader can't recover it. That's why you can't re-display it after the initial creation.

Verifying email manually

If email delivery is broken and a user is stuck on the email-verification wall, Verify email marks the address verified without sending anything. Use sparingly — the verification step exists for a reason (confirm the address is real before giving out notifications) — but it's the right escape hatch for bootstrap scenarios.

Disabling MFA

When a user loses their TOTP device with no backup codes left, they can't log in. Disable MFA turns off TOTP for that account:

• Clears the TOTP secret.
• Deletes unused backup codes.
• The user can log in with just their password until they re-enroll.

Backup codes are the first line of recovery — every user gets eight single-use codes when they enable MFA, printable at enrollment time. Disable MFA is the last resort.

Per-user permissions

Beyond group membership, you can grant permissions directly to a single user. This is the fine-grained escape hatch — a user needs one specific capability that isn't covered by any existing group, and making a new group for one user is overkill.

The Permissions tab on the user detail drawer shows:

• Direct permissions — attached to this user specifically.
• Effective permissions — direct + inherited from every group the user is in, annotated with the source ("direct" or a group name).

Add permissions and Remove permissions accept a list of permission IDs — the UI exposes a picker that groups permissions by Django app label (queries, apic_connections, awx, …) with descriptive labels.

Audit trail

Every action on this page is audited:

All entries carry the admin's username, IP address, and the affected user's username. See the Audit logs page for how to browse and export them.

Rate limiting

All mutating actions on this page go through SensitiveActionThrottle, which is stricter than the default user throttle. Read-only actions (list, retrieve, view permissions) use the default user: 300/minute throttle so admin browsing isn't slowed down. If you hit the throttle while doing bulk work, slow your cadence — or script the operation through the Django management shell where throttles don't apply.

Common tasks

• Onboarding a new admin. Create the user, add to the Admin group, verify email, have them log in and enable MFA. That's it.
• Offboarding. Deactivate rather than delete. Keep their audit trail intact. Transfer ownership of shared resources before deactivation if the former user owns scheduled tasks that need to keep running.
• "I lost my phone." Verify identity out-of-band, Disable MFA, user logs in with password, user re-enrolls TOTP with a new device.
• "I forgot my password and my email is broken." Generate reset code, deliver out-of-band, user resets within 30 minutes.
• "I want to promote a user to admin." Edit the user, add to the Admin group. No further steps — the Admin group is a bypass for all permissions.

---

Users are the who. Groups and quotas are what they're allowed to do and how much. The next page covers both.