Managing users

The Users page lists everyone who can sign into RebelCore™ for your customer. It’s visible to anyone with the Add Users permission (or the Customer Super Admin, who always sees it).

Who shows up in the list

The list combines two kinds of accounts:

• The Customer Super Admin for your customer, marked with an OWNER badge. This account is the one that was set up when the customer was provisioned and cannot be edited or deleted from this page.
• Every app user scoped to your customer (customer_id matches yours) with a product system_type (REBELCORE, VIOCORE, ELYVRA, or REBELCOREAGENT). CAS-only users never appear here.

The list is strictly customer-scoped: even a Customer Super Admin only sees users belonging to their own customer.

Creating a user

1. Click the floating + button on the bottom-right.
2. Fill in First name, Last name, and Email.
3. Pick a Role — the dropdown shows the system roles plus any custom roles you’ve created for this customer.
4. Pick a Status (defaults to Active).
5. Click Create.

There is no temporary password. RebelCore™ creates the user without a password set and emails them an invite link:

• The link lands on a Set your password page; the user picks their own password subject to the platform policy (at least 12 characters, mixed letters + digits).
• The link is valid for 24 hours. After that the user needs a fresh one — see Resend invite below.
• The link is single-use — once the user successfully sets their password it’s burnt.
• Until the user completes registration their account is inactive and sign-in is refused; the moment they set their password the account flips to active.

The blade shows a confirmation banner — “Invite email sent to alice@example.com” — once create succeeds. You don’t see the password and there’s nothing to copy.

Note

The user is also created with must_change_password = 1 and totp_required = 1. On their first portal sign-in they’re walked straight into the TOTP enrolment flow (QR code + backup codes). Agent-only users skip TOTP enrolment and use email-OTP instead.

What you can’t set

The create form only exposes safe fields. Two things are deliberately not surfaced:

• system_type is hard-coded to REBELCORE on the server. There is no way to mint a CAS account from the rebelcore UI — even a hand-crafted API call ignores any system_type value in the payload.
• customer_id is forced to the principal’s own customer. A Customer Super Admin can’t create users for another tenant.

Editing a user

Click any non-owner row (or the Edit action) to open the user blade. You can change name, email, role, and status. Changes take effect on the user’s next request — no sign-out required.

Resend invite

When editing an existing user, the blade has a RESEND INVITE button. Clicking it:

• Burns any outstanding invite/reset token for that user — old links stop working immediately.
• Mints a fresh registration token (24-hour TTL) and emails them a new link.
• Logs the resend as an Activity event (user.invite_resent).

Use this when:

• The user lost the original email.
• The original link expired before they got to it.
• You suspect the original email was leaked or forwarded — burning + re-sending replaces it.

There is no admin-side “set this user’s password” button for portal users. The platform deliberately keeps the user as the only party who ever knows the cleartext — see Why no admin password reset below.

Forgot password (user-initiated)

A user who has already completed registration but forgotten their password can self-serve from the sign-in form’s Forgot password? link — RebelCore™ emails them a reset link (1-hour TTL, single-use). Admins don’t need to be involved unless the user can’t access the registered email address, in which case Resend invite is the right escape hatch (it both invalidates the old password and mints a fresh setup link).

Why no admin password reset

In earlier versions admins could click Regenerate password and read out an 8-character temporary password. That’s gone. Two problems made it unsafe:

1. The admin could see the plaintext, which means it had to be communicated over some out-of-band channel (Slack, email, voice) — every channel has its own leak vector.
2. The user inherits a password they didn’t pick; muscle-memory says “first thing I do is keep using this one”, so a chunk of users never changed it.

The invite-link flow fixes both — only the user ever sees a cleartext password, and they’re forced to choose it themselves.

Deleting a user

The Delete action removes the app_user record (and cascades their customer_user_role link). The Customer Super Admin row never has a Delete action — to remove a Customer Super Admin you go through the CAS provisioning flow.

Resetting two-factor

If a user loses their authenticator app and their backup codes, their Customer Super Admin can clear their TOTP enrolment via the user blade. The user’s totp_required flag stays on, so on their next sign-in they’re walked through enrolment again from scratch. Old backup codes are invalidated as part of the reset.

Lockouts

After 5 consecutive failed sign-in attempts (wrong password or wrong second-factor code), an account is locked for 15 minutes. The user blade surfaces the lockout state and lets a Customer Super Admin clear it immediately if access is urgent. A successful sign-in resets the counter.

Permission propagation

When you change a user’s role, or change a role’s flags, no sign-out is needed. The next call to /auth/core/me (which the front-end issues at every page load) re-evaluates the user’s permission block from the database. Buttons appear or disappear, and backend guards switch over, on the next request.

If you want to be sure a user is on the latest permissions immediately, ask them to refresh their browser tab.

Where to go next

• Signing in — the invite/TOTP/forgot-password flow from the user’s perspective.
• Roles & permissions — the full reference for what each flag controls.
• Audit — review what each user has been doing in the platform.