Crazy

[ADMIN] Platform user invitation flow

Type: Story · Epic: — (new, not part of EVO-4476)

—

Problem

There is no way to create an admin portal user. POST /users (create-user) is commented out at user.controller.ts:105-150, so the only path to an admin account is the boot seeder reading ADMIN_EMAIL/ADMIN_PASSWORD. Adding a colleague means promoting an existing artist account that signed up through the client portal.

Separately, the User Roles page listed every user in the system — 168 rows, almost all customers — in a screen whose only purpose is granting staff access.

Solution

Invite platform users by email from the User Roles page. The invitee gets a time-limited link, sets a password, and lands on login. The page now lists only platform users.

this is great

Scope

Backend (artist-admin)

POST /api/users/invite — name, email, role IDs. Creates a pending password-less user with roles attached, emails a set-password link. New users:invite-platform-user permission.
POST /api/users/:userId/invite/resend — new token (old link dies), re-sends.
GET /api/auth/invite/verify + POST /api/auth/invite/accept — public; the invitee has no credentials yet.
findAdminUsersWithRoles filters to users holding ≥1 active isPortalRole role.
Reuses the existing invite-user.template.hbs, Invitation schema, and EmailsService.

Frontend (fe-artistevolve-admin)

“Invite User” button + modal (name, email, portal-role picker), permission-gated.
Resend action on pending rows with success/error notice.
New public /auth/set-password page: verify token → set password → redirect to login.

Design decisions

Token = selector.secret. Selector indexes the lookup; secret stored only as a bcrypt hash. A DB read can’t be replayed into an account takeover.
7-day expiry, resend regenerates. Resend invalidates the previous link.
Uniform error for invalid / expired / already-used, so the endpoint can’t enumerate which emails have pending invites.
Existing email → 409, not a silent upgrade. Promoting a client user to staff is a deliberate act on the User Roles page.
Invite roles run through canGrant — can’t invite someone with more access than you hold. Non-portal roles rejected.
Public pages use a separate publicApi client — the normal one’s 401 handler clears storage and hard-redirects to /auth, which would bounce invitees off the page they were sent to.