3.7 KiB
Staff workspace and access control
Status: implemented. The staff workspace starts at /admin and uses
database-checked permissions on every protected route and context operation.
Navigation visibility is only a usability aid; it is not the authorization
boundary.
Role model
A confirmed account can hold any combination of these fixed roles:
| Role | Access |
|---|---|
support |
Verified support queue, assignment, conversation, status, and response |
moderator |
Reports, scoped evidence, abuse signals, request/activity moderation, user restriction, and category proposals |
legal |
Content-removal and TAKE IT DOWN queue, assignment, status, and decision |
analyst |
Aggregate privacy-preserving product analytics |
admin |
Every staff permission, role administration, user administration, and audit log |
Permissions are the union of all assigned roles. For example, one account may
hold both support and moderator. The ordinary user state is represented by
having no staff-role assignments; user is not a staff role.
The matrix is deliberately fixed in
WhoNeedHelp.Accounts.StaffPermissions. The UI cannot create arbitrary roles
or attach one-off permissions, which keeps review and auditing unambiguous.
Workspaces
/admin— permission-scoped operational totals and the current account's staff roles./admin/users— account search and filtering, restriction/suspension, and multi-role assignment. Moderators can act on ordinary accounts; administrators can also act on staff accounts and change roles./support/operations— support and legal queues. Each section is rendered only when the operator has its permission. Cases can be filtered and assigned only to an active account that can manage the matching queue./moderation— reports, scoped evidence, abuse signals, hidden content, and category proposals./analytics— aggregate metrics for analysts and administrators./admin/audit— administrator-only, cursor-paginated audit records with actor, action, target, timestamp, and stored metadata.
Administrative safeguards
- Role changes require an active administrator and a session authenticated in the preceding ten minutes. A stale session receives a forbidden result and must authenticate again.
- The final active administrator cannot lose the
adminrole and cannot be restricted or suspended. - A staff account can be restricted or suspended only by an administrator. A moderator cannot change another staff account.
- An operator cannot restrict or suspend their own account.
- Suspending an account deletes its login tokens, disconnects active LiveView sessions, and stops/deletes current live-location state.
- Changing staff roles disconnects the affected account's active sessions so the next session loads the new permission set.
- Assignment is validated on the server. A support case cannot be assigned to a legal-only or ordinary account, and a legal case cannot be assigned to a support-only or ordinary account.
- Sensitive changes record audit events. Audit rows are not editable from the staff UI.
First administrator
After the first account has registered and confirmed its email, bootstrap the initial administrator exactly once:
./scripts/bootstrap-admin.sh you@example.com --confirm
The command refuses to run after an administrator exists and records an audit
event. All subsequent role changes are made from /admin/users.
Operational checks
Before granting access, confirm that the person needs the smallest applicable role or role combination. After a change, verify the corresponding audit event and ask the operator to start a new session. Regularly review unassigned support and legal queues, suspended staff accounts, and the audit log.