#Permissions & Users

Admin management is meant to happen entirely from the Users page (in-game or on the web dashboard) - not by editing config.lua or server.cfg ACE principals.

#How a role is resolved

For any given admin, the resource checks, in order:

1. A row in the admin_roles database table (set via the Users page or /setrole).
2. The framework's native permission group - QBCore's god/admin ACE groups, or the player's ESX group.

If neither exists, the player isn't an admin.

#Roles vs. custom permissions

Each role (god, admin, mod, helper) has a default list of allowed actions defined in Config.Permissions. That's just a starting point - from the Users page, a god admin can give any individual admin a fully custom permission set (a checkbox grid grouped by category: Panel, Moderation, Reports & Chat, Economy & Character, World & Server, Vehicles, Self Toggles, Developer Tools). A custom set completely replaces the role default for that one person; "Reset to role default" clears it.

Under the hood this is one JSON column (admin_roles.permissions_override) and one function, Permissions.Can(admin, action), that every single action/query/command in the resource calls - so overrides are respected everywhere, with no exceptions to remember.

#Managing admins

From the Users page you can:

• Add an admin - pick an online player or type their identifier, choose a starting role. Typing discord:<their Discord user ID> as the identifier works too - that's what controls someone's permission level on the web dashboard specifically (see Web Dashboard), independent of whether they're an in-game admin at all.
• Change role - reassign anyone between the four presets.
• Edit permissions - open the checkbox grid to customize exactly what one admin can do.
• Remove - revoke admin access entirely.

The same is available in-game with:

/setrole [server id] [role]

#Role seniority

Roles are ranked god > admin > mod > helper, and that ranking is enforced on every role change:

• Nobody can grant a role more senior than their own.
• Nobody can change the role of, or edit the permissions of, an admin more senior than they are.

Without this, manageroles (which admin holds by default) would effectively be "promote yourself to god". The server console bypasses the check, which is what makes it the way back in if you ever lock yourself out of your own panel.

Custom permission sets are also validated against Config.PermissionCatalog, so a typo'd action name is rejected rather than stored as a permission nothing can ever satisfy.

#The web API credentials

This is a separate, simpler system from the admin roles above. Each server has exactly one API token and one dashboard secret (not one per admin), created together from the panel's Users -> Web dashboard access card. Every Discord account you grant access to on the dashboard shares them - see Web Dashboard for how that access is managed.

The two do different jobs:

• The token authenticates the connection. On its own it carries no permissions at all (see Config.API.ServerTokenRole in Configuration).
• The secret signs who is acting on each request, which is what lets your server apply that person's own admin_roles role rather than a shared fallback.

Generating them requires the manageapitokens permission (god by default), and can only be done from inside the game - a request coming from the dashboard would revoke the very token it was authenticating with.

The values are displayed once, in the panel, with copy buttons. The token is stored as a SHA-256 hash and can never be shown again: that's deliberate, and it means someone who reads your database still can't authenticate as your dashboard connection. Generating a new pair invalidates the old one immediately, so update the dashboard afterwards using Edit connection - that keeps every access grant on the server, unlike removing and re-adding it.

If nobody can open the panel, apitoken regenerate works from the server console. It deliberately does nothing in-game: a chat command would put live credentials into chat.