who_need_help/docs/staff-operations.md

82 lines
3.7 KiB
Markdown

# 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 `admin` role 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:
```bash
./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.