User Management
Backoffice path: backoffice/users
Available to roles: System Administrator, Administrator
Overview
The User Management page is the central hub for administering pilot accounts across your virtual airline. From here you can create new accounts, edit existing profiles, assign roles and permissions, and remove users when necessary.
User List
The main view displays a paginated table of all registered users with the following columns:
| Column | Description |
|---|---|
| Name | The pilot's full name |
| Account email address | |
| Airport | The pilot's currently assigned home airport (ICAO code) |
| Rank | Current rank within the airline |
| Status | The pilot's status: Active, Inactive, Hidden or Banned |
| Roles | Assigned roles displayed as colored badges (e.g., sysadmin, administrator, operations-staff) |
| Created At | The date and time the account was created |
Sorting and Searching
All columns in the user list are sortable. Click any column header to sort ascending or descending.
Use the search bar to filter users by:
- Name -- partial or full name match
- Email -- partial or full email match
- Airport -- ICAO airport code
The status filter next to the search bar narrows the list to one status. Hidden and banned pilots only appear here — never on the roster.
Creating a User
To create a new user account, click the Create button at the top of the user list. Fill in the following fields:
| Field | Required | Description |
|---|---|---|
| Name | Yes | The pilot's full name |
| Yes | A unique email address for the account | |
| Password | Yes | Initial password for the account |
| Airport | Yes | Home airport assignment (ICAO code) |
| Rank | Yes | Starting rank within the airline |
| Roles | No | One or more role checkboxes: sysadmin, administrator, operations-staff |
If no roles are selected, the user is created as a regular pilot with no backoffice access.
When pilots register through the self-service registration form, they must verify their email address before they can book flights. A verification email is sent automatically upon registration. Unverified pilots can still browse the platform (dashboard, fleet, roster, schedules) but are redirected to a verification notice when attempting to access the booking page.
Editing a User
Click on any user in the list to open their edit page. The edit page is divided into several sections.
Profile Information
Update the following fields for an existing user:
- Name -- the pilot's display name
- Email -- account email address
- Airport -- reassign the pilot's home airport
- Rank -- change the pilot's current rank
Role Assignment
Roles are managed via checkboxes on the edit page. Check or uncheck roles to sync the user's role assignments:
- System Administrator (
sysadmin) - Administrator (
administrator) - Operations Staff (
operations-staff)
Role changes take effect immediately upon saving.
Direct Permissions / Abilities
In addition to role-based permissions, you can grant specific abilities directly to a user. This allows fine-grained access control that bypasses the standard role definitions. Use the permissions section on the edit page to sync individual abilities for the user.
Pilot Licenses
The edit page includes a licenses panel showing every license ever assigned to the pilot (active, expired, or revoked), with the status, issue date, expiry date, and last renewal date for each.
From this panel you can:
- Assign a license — select a license from the dropdown and click Assign. Licenses the pilot already holds an active version of are excluded from the dropdown; revoked or expired licenses remain eligible for re-assignment.
- Release an exam — if the selected license requires passing an exam, click Release Exam to create an exam assignment for the pilot instead of issuing the license directly.
- Revoke a license — click Revoke next to any license with an active or suspended status to revoke it.
A suspended license shows the date its suspension ends. Suspended licenses are excluded from the assign dropdown.
Suspensions
Staff with the Suspend pilots ability can suspend the pilot from booking altogether, or suspend one of their licenses, for a number of days. See Suspensions.
This mirrors the license holder management available from the license's own edit page (backoffice/licenses/{license}/edit), so licenses can be managed from either the license or the pilot's side.
Pilot Status
Every pilot has a status, shown on the edit page with the date it last changed, who changed it (or "the system"), the reason, and the pilot's last activity.
| Status | Set by | Roster | Can log in | Can book |
|---|---|---|---|---|
| Active | Staff, or the system when an inactive pilot flies back in | Listed | Yes | Yes |
| Inactive | Staff, or the system after INACTIVITY_DAYS without flying | Listed, marked Inactive | Yes | Only when self-reactivation is on and their rank has a free seat |
| Hidden | Staff only | Not listed — for anyone, staff included | Yes | No |
| Banned | Staff only | Not listed | No | No |
Inactive. With PILOT_AUTO_DEACTIVATION on, a nightly job marks pilots inactive once their inactivity clock has run past INACTIVITY_DAYS. The clock restarts when the pilot joins, is made active, or files a flight that is not rejected, so a pilot just let back in is never deactivated the next night for an old last flight. A pilot holding a live booking (for example, mid-flight) is never deactivated. With INACTIVE_SELF_REACTIVATION on, the pilot's next accepted (or warned) flight makes them active again — but only a flight flown after they went inactive, and only if their rank has a free seat. Otherwise they stay inactive and cannot book until staff reactivate them. Staff reactivation works even when the rank is full.
Hidden. Behaves as inactive, and also takes the pilot off the roster, rankings, leaderboards, the public API and Discord rankings, exactly like the pilot's own Invisible mode — but it never changes their privacy settings, so lifting it restores whatever they chose. Flying never lifts it.
Banned. Everything hidden does, plus:
- The pilot is signed out everywhere: web sessions, remember-me, ACARS tokens and device codes, and MCP connector tokens. Login (password and VATSIM) refuses them, and API keys they created stop working.
- Their bookings are cancelled, charter missions they hold reopen without a penalty, their ferry legs pass to the next pilot, and pending rank applications are withdrawn.
- Their email, VATSIM ID, IVAO ID and Discord ID cannot register or link another account — even if the banned account is later deleted. The email is kept only as a one-way hash.
- Unbanning makes the pilot active and lifts the identity block.
Who can change it. Changing a status needs the permission to edit users. Banning and unbanning also need the permission to delete users. Nobody can change their own status, and only a sysadmin can change a sysadmin's. Banning and unbanning are only available in the backoffice — the MCP update-pilot tool can set active, inactive or hidden.
Every change is written to the pilot's activity log with the reason. The reason is never shown to the pilot.
Every change — by staff or by the system — is also posted to the Discord staff channel, when one is configured: the old and new status, who made the change (or "System"), and the reason.
Pilot Record (Staff Notes)
The edit page includes the user's pilot record: free-text notes staff keep on the user — warnings given, conversations had, anything the next reviewer should know. Notes show who wrote them and when, newest at the bottom, with a box to add another.
The record is staff-only: the pilot never sees it, not even their own. Reading and adding notes needs the view-notes and add-notes abilities on users, and removing one needs delete-notes (see Notes Abilities).
The same record opens from the Pilot record button while reviewing any of the user's flights — see Flights.
Activity Log
The user edit page includes a paginated activity log showing two categories:
- Changes to this user — Every edit to the user's profile fields (name, email, airport, rank, etc.) is recorded with timestamps and who made the change.
- Actions by this user — Staff actions performed by this user on other models (e.g., approving flights, moving aircraft) are displayed in a second table.
This provides a complete audit trail for both administrative changes to a pilot's account and the pilot's own staff actions.
Password Reset
A separate password reset form is available on the user edit page. Enter the new password and confirm it to update the user's credentials. This is independent of the profile information form and must be submitted separately.
Roles Overview
Users can be assigned one or more of the following roles. Each role grants a different level of backoffice access:
| Role | Key Abilities | Description |
|---|---|---|
| System Administrator | everything | Full, unrestricted access to every feature in the platform. |
| Administrator | see-admin-options + model-level permissions | Access to most management features including airlines, airports, schedules, fleet, users, settings, and more. |
| Operations Staff | see-admin-options + limited permissions | Restricted access to documents, licenses, spotter photos, and ferry flights. |
Regular users (pilots) do not have any backoffice roles assigned and cannot access the administration panel. Only users with at least one role that grants the see-admin-options ability will see the backoffice navigation.
Deleting a User
Deleting a user always erases the account permanently, whether the pilot deletes it from Settings, staff delete it from the backoffice or the private API, or a platform admin deletes it from central. There is no "deleted" state to restore from.
Before the account goes, work the pilot is holding is handed back to the airline:
| Pilot was holding | What happens |
|---|---|
| Bookings | Cancelled. Repositioning, charter, tour and ferry legs booked through them are released. |
| Charter mission (assigned or in progress) | The pilot is taken off and the mission goes back on the board. |
| Ferry legs | Their places in leg queues are dropped. A leg they were flying goes to the next pilot in its queue. |
Then the pilot's data is removed: flights, points, tour progress and awards, license assignments, exam assignments, rank applications, notifications, staff notes about them, activity log entries, tokens, and profile picture.
Records a staff member set up for the airline stay: tours, charter missions and the Discord integration keep working, with no creator shown. Ferry flights they created and API keys they issued are deleted with them.
Deleting a banned pilot does not lift the ban: their email and network IDs stay blocked from registering again. To let them back, unban them before deleting the account.
Deleting a user cannot be undone.
Central (Platform Admin) User Management
Central path: tenants/{tenant_id}/users
Available to: Platform administrators (central app)
In addition to managing users from within a tenant's backoffice, platform administrators can manage any tenant's users directly from the central dashboard. This is useful for support operations and account administration without needing to log into each tenant individually.
Accessing Central User Management
- Navigate to Tenants in the central dashboard.
- Click on a tenant to open its edit page.
- Click the Manage Users button in the header area.
Available Actions
The central user management interface mirrors the backoffice user CRUD with the following pages:
| Page | Path | Description |
|---|---|---|
| User List | tenants/{id}/users | Paginated table with search, sort, and delete — identical columns to the backoffice user list |
| Create User | tenants/{id}/users/create | Create a new user in the tenant's database with name, email, password, airport, rank, and roles |
| Edit User | tenants/{id}/users/{user_id}/edit | Edit user details, assign/retract roles and direct permissions, reset password |
Key Differences from Backoffice User Management
- No plan limits: Central admin bypasses the tenant's
UserLimitService— users can be created regardless of the tenant's plan restrictions. - No tenant-level authorization: Actions are not gated by the tenant's Bouncer permissions since the platform admin operates outside the tenant's permission context.
- No activity log panel: The edit page does not include the activity log component (which is tenant-scoped).