Browse docs
Permissions
server.cfg and your player is in group.admin. Sky now wires every per-command permission to ACE automatically — no more Sky.Config.AdminGroups.How Sky checks command permissions
Every admin command (/revive, /setboss, /hospitalcreator, …) is gated by Config.CommandPermissions in the job's config. At server start, sky_base reads that table and emits one add_ace per command × group:
Config.CommandPermissions = {
revive = { "god", "superadmin", "admin" },
stopdeathtimeout = { "god", "superadmin", "admin" },
refunds = { "god", "superadmin", "admin" },
hospitalbeds = { "god", "superadmin", "admin" },
hospitalcreator = { "god", "superadmin", "admin" },
removemobilityaid = { "god", "superadmin", "admin" },
kill = { "god", "superadmin", "admin" },
}
For the snippet above, sky_base runs at boot:
add_ace group.god sky_ambulancejob.revive allow
add_ace group.superadmin sky_ambulancejob.revive allow
add_ace group.admin sky_ambulancejob.revive allow
… one block per command
On QBCore, sky_base additionally wires the qbcore.<group> principal for resilience. At runtime each command resolves with a single IsPlayerAceAllowed(src, "sky_ambulancejob.<command>").
If a command is not listed in Config.CommandPermissions, only the server console can use it.
Framework setup
QBox (principal prefix: group.)
Add your admin player to group.admin:
add_principal identifier.license:<license> group.admin
Reference: Qbox txAdmin permissions recipe.
QBCore (principal prefix: qbcore. or group.)
sky_base wires both group.<g> and qbcore.<g> on QBCore, so either prefix works:
add_principal identifier.license:<license> qbcore.admin
Or, if an existing admin is already online:
/addpermission 1 god
ESX Legacy (users.group)
ESX's setGroup automatically calls add_principal identifier.<license> group.<g> via es_extended, so ESX players get the same ACE principal as QBox/QBCore. Grant the group in-game:
/setgroup 1 admin
Or via SQL:
UPDATE users SET `group` = 'admin' WHERE identifier = 'license:<license>';
References: ESX /setgroup, ESX principals.
vRP
Set the player's group via your vRP admin tooling, then ensure the group.<g> principal is registered (vRP setups commonly add this to server.cfg).
Custom groups
To allow another group (for example supporter) to use a single command, just add it to the relevant entry:
Config.CommandPermissions = {
revive = { "god", "superadmin", "admin", "supporter" },
…
}
Then grant the player the principal the same way as above (e.g. add_principal identifier.license:<license> group.supporter), and restart sky_ambulancejob so the new wiring runs.
Activating the boss menu with /setboss
Once your admin group is set, run /setboss to grant every permission (boss menu, wholesale, vehicle shop, member management, …) to a specific job grade:
/setboss ambulance 4
This writes Permission.ALL to the sky_job_permissions row for that job and grade. Only run it once per fresh install or after wiping sky_job_permissions.
See the Commands page for the full admin command list.
Troubleshooting
::accordion-item{label="Command says "No permission""}
Player is not in any of the groups listed for that command in Config.CommandPermissions, or the bootstrap ACEs are missing. Restart the server after editing server.cfg.
::
The player must reconnect after the change. After server.cfg edits, run refresh + load permissions in the console or restart the server.
Add the group string to the relevant Config.CommandPermissions[command] array, then grant the principal (add_principal … group.supporter) and restart the resource.
Grade mismatch. The grade you passed to /setboss must match the value in sky_job_members.grade for that employee. Check the DB, or use the highest grade configured for the job.
sky_jobs_base is not running. It must start before sky_ambulancejob in server.cfg.
Support
Need help? Our support team is always ready to assist
Join Discord