User Management
Turqoa uses role-based access control (RBAC) to manage user permissions. Administrators can create, modify, and deactivate user accounts through the Admin panel or the CLI.
Creating Users
Via Admin Panel
- Navigate to Admin > User Management > Create User.
- Fill in the required fields:
- Email (used as the unique identifier)
- First name and Last name
- Role (select from available roles)
- Authentication method (SSO or local)
- Click Create. If using local authentication, a password reset link is sent to the user's email.
Via CLI
turqoa admin users create \
--email operator@terminal.example.com \
--first-name Jane \
--last-name Smith \
--role operator \
--auth-method sso
Via API
curl -X POST https://turqoa.example.com/api/v1/admin/users \
-H "Authorization: Bearer ${ADMIN_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"email": "operator@terminal.example.com",
"first_name": "Jane",
"last_name": "Smith",
"role": "operator",
"auth_method": "sso"
}'
Role Assignment
Each user is assigned exactly one primary role. Roles determine what the user can see and do in the Command Center and Admin panel.
Available Roles
| Role | Description | Key Permissions |
|---|---|---|
admin | Full system access | User management, system config, all operational features |
operator | Gate transaction processing | View/review/approve/reject transactions, Command Center access |
security_operator | Security monitoring | Security feeds, incident management, drone dispatch |
supervisor | Elevated operator | All operator permissions + override review + shift management |
viewer | Read-only | Dashboard viewing, report access, no action capabilities |
api_consumer | Machine-to-machine | API access only, no UI access |
Changing a User's Role
turqoa admin users update \
--email operator@terminal.example.com \
--role supervisor
Role changes take effect immediately. The user's current session is updated without requiring re-login.
Permission Model (RBAC)
Turqoa's RBAC model is structured around resources and actions.
Permission Matrix
| Resource | admin | supervisor | operator | security_operator | viewer |
|---|---|---|---|---|---|
| Gate transactions | CRUD | CRUD | RU | R | R |
| Security incidents | CRUD | CRUD | R | CRUD | R |
| Drone dispatch | Yes | Yes | No | Yes | No |
| User management | CRUD | R | No | No | No |
| System configuration | CRUD | R | No | No | No |
| Audit logs | CRUD | R | R | R | R |
| Reports | CRUD | CRUD | R | R | R |
| AI model management | CRUD | No | No | No | No |
Legend: C = Create, R = Read, U = Update, D = Delete
Custom Permissions
For deployments requiring granular control beyond standard roles, administrators can create custom permission sets:
custom_roles:
- name: gate_supervisor
base_role: operator
additional_permissions:
- gate.override.review
- gate.shift.manage
- reports.gate.export
restricted_permissions:
- security.incidents.manage
Deactivating Users
Deactivated users cannot log in but their records are preserved for audit purposes.
Via Admin Panel
- Navigate to Admin > User Management.
- Search for the user by name or email.
- Click Deactivate. Confirm the action.
- The user is immediately logged out of all active sessions.
Via CLI
turqoa admin users deactivate --email former-operator@terminal.example.com
Reactivation
Deactivated users can be reactivated by an administrator:
turqoa admin users activate --email returning-operator@terminal.example.com
Note: Turqoa does not support permanent user deletion. This is by design --- all user records are retained indefinitely for audit trail integrity. Deactivated users do not count against license seat limits.
Audit of User Actions
Every user action is recorded in the audit log with the following attributes:
| Field | Description |
|---|---|
timestamp | UTC timestamp of the action |
user_email | Email of the user who performed the action |
user_role | Role at the time of the action |
action | The action performed (e.g., transaction.approve, user.create) |
resource_type | The type of resource acted upon |
resource_id | The unique identifier of the resource |
details | Additional context (e.g., override justification, changed fields) |
ip_address | Source IP of the request |
session_id | The user's session identifier |
Administrators can query user activity from the Audit Logs section or via the API. See Audit Logs for details.