User management

This is where you create staff accounts, change roles, and handle deactivation and account recovery. It’s separate from the client portal, which has its own, much narrower account management.

Settings → Users manages staff accounts only: Superadmin, Team Lead, Senior, Consultant, and any custom role you’ve created. It needs the permission to manage users, and client-portal accounts aren’t handled here at all.

Creating a user

From Settings → Users, choose New user, and set a username, email, and role. What happens next depends on how your instance handles login.

• Local login (the default): the account is provisioned through the same single-use, 24-hour emailed setup link used everywhere else in RedScribe. You never set a new user’s password yourself; they set their own from the link, then enroll in two factor authentication on first login.
• OAuth login (Google or Microsoft, if configured): the account is created as a pending invite instead. No email goes out, and there’s nothing to choose between local and OAuth, since that’s decided once for the whole instance. The account activates automatically the first time someone signs in with that exact email address through your identity provider. Superadmin can’t be created this way; the form blocks that role choice, since that account needs the command line setup path instead. If your instance also restricts sign ins to a specific email domain, the invite’s address has to match it, or it could never be claimed. See OAuth provisioning for how claiming actually works.

A pending invite shows an amber “Invited — awaiting first login” badge until it’s claimed.

Active and deactivated accounts

The user list has two tabs: Active and Deactivated, each showing how many accounts it holds. Search and paging stay on the tab you’re viewing. A deactivated account can be reopened from its tab and reactivated from its detail page.

Accounts can’t be deleted outright, on purpose. Everything a person did stays tied to them: the audit log, finding authorship, comments, and checklist history. Deactivating removes their access without breaking that record. Wherever a deactivated person still appears in the app, such as a finding’s author or reviewer, a checklist assignee, or an audit log row, their name is followed by “(deactivated)”. Reports, emails, and the audit CSV export use the plain name.

Erasing a deactivated account

Erasing is a last resort, not the normal way to offboard someone. Deactivating already removes all access while keeping the person’s name on their work; reach for erasure only when the personal data itself has to go, such as a data-subject erasure request. It’s irreversible and strips the name from everything they did.

When someone’s personal data has to go, open their deactivated account and choose Erase account. Only deactivated staff accounts can be erased, and you can’t erase your own. Erasing:

• removes their name, email address, password, two factor devices, notifications, engagement memberships, and any linked OAuth sign-in;
• frees their username and email for reuse;
• keeps the account record itself, shown as “Erased user” followed by a short code, so findings, comments, checklist history, and the audit log stay attributed and the audit log’s integrity check still passes.

It can’t be undone, and the account can never be reactivated or edited. To confirm, you type the account’s exact username into the confirmation field — there’s no second approver and no password step. The erasure is recorded in the audit log against whoever performed it.

The audit log keeps the old username

Audit entries already written keep the username as it was, because the log is tamper-evident and can’t be rewritten. They disappear when they pass your retention period. Erased accounts’ sign-in attempt records are renamed, since those aren’t part of the integrity chain.

Managing an existing user

A user's detail page. Account actions sit on the right; which ones appear depends on the account.

From a user’s detail page:

• Edit changes email, name, or role. You can’t change your own role from here, so get another Superadmin to do it if that’s ever needed.

• Deactivate signs the account out of every active session immediately and blocks further login. Two safeguards stop you from locking yourself, or the whole instance, out:

  • You can’t deactivate your own account.
  • You can’t deactivate the last active Superadmin.

  Deactivating someone doesn't reassign their work

  If the person you’re deactivating still has findings assigned to them for review or QA, those assignments aren’t moved anywhere automatically. You’ll see a warning listing a few of the affected findings, plus a count of any more, so you know to hand them off to someone else. Nothing reassigns itself until you do.

• Reactivate restores login access without touching their role or existing assignments.

• Send password reset sends the same emailed reset link someone would get from “Forgot password” themselves. Local accounts only.

• Clear MFA wipes the account’s enrolled authenticator, forcing them to set up a new one at next login. Also local accounts only.

• Convert to local account flips an OAuth account back to local login, clears any pending invite state, and sends the standard 24-hour setup email. This is the fallback for an OAuth account that’s lost its way to sign in, most commonly because OAuth login got turned off for the instance after the account was created. The detail page flags that situation with a warning of its own.

• Convert to OAuth does the reverse: turns a local account into a pending OAuth invite, provided OAuth login is actually configured on the instance. It’s blocked for Superadmin, since that role is local-login only, and blocked if the account’s email doesn’t match your instance’s allowed sign-in domain (when one is set), since that invite could never be claimed.

The same last-active-Superadmin protection applies to changing someone’s role away from Superadmin: RedScribe blocks it and tells you to make another account Superadmin first, rather than ever letting an instance end up with none.

Account recovery (lost password / lost MFA device)

There’s no self-service recovery for a local account that’s lost its password, its authenticator, or both. This has to be fixed directly on the server, using a dedicated recovery command rather than reaching into the database by hand. It’s the escape hatch for when the tools above aren’t usable, most importantly when the only Superadmin is the one locked out, and because it’s the one access path that matters most during an actual incident, running it writes its own entry to RedScribe’s audit log rather than leaving no trace at all.

1. Find the username, if you don’t already know it. From the server:

   docker compose exec web python manage.py shell -c "
   from apps.accounts.models import User
   for u in User.objects.filter(role__is_superadmin=True):
       print(u.username, u.email)
   "

2. Reset the password, and clear MFA in the same step if that’s lost too:

   docker compose exec web python manage.py emergency_account_recovery \
     --username <username> --reason "<why this is being run>" --clear-mfa

   This prompts for the new password interactively (input hidden) and asks you to confirm it. Drop --clear-mfa if only the password is lost. --reason is required and gets recorded verbatim in the audit log entry, along with who ran it (your current OS user by default, or --operator <name> to record someone else).

Log in with the new password. With no enrolled authenticator left, the account is routed straight into MFA setup to add a fresh one.

Danger

Never resort to restoring the whole database over a single lost credential; that destroys every engagement, finding, and report along with it. Account recovery touches only the one affected user. If you do need to restore from a backup for some other reason, see Backup & restore, which has its own safeguards around account state.