Ace permissions

On resource 1.8.9 an ace right grants nothing. What a player may do in game is decided by the list of abilities on their In-Game Moderators row and by nothing else, so an add_ace line in server.cfg neither opens the menu, nor runs a command, nor exempts a detection. The rac names are still read, but only so the server can report who holds one. This page says what that means for a server.cfg that already grants them, what replaced each one, and what a whitelist actually exempts, which is the one thing here that still changes behaviour.

What replaced each right

Every right maps onto one of the fourteen abilities on an In-Game Moderators row, except the two that were only ever a gate on reaching Raven at all. Two of them split in the move, which is the only real change in shape: kicking and banning are separate now, and so is each entity type.

Admins and moderators lists all fourteen with what each one unlocks on both sides, and Commands maps them onto each rac subcommand and each page of the menu.

What Raven still does with them

One thing, and it is a report rather than a decision. The game server can take a snapshot of which connected players hold a rac right, probing each of them against twenty-four names. A player who holds the broad rac is reported as holding that and the narrower names are not probed for them; anyone else is reported with every narrower name that matched. A player who holds none is left out of the snapshot entirely. One snapshot is kept for ten minutes before the server will build another.

The names it looks for

rac

rac.commands
rac.menu
rac.entities
rac.players.action
rac.players.stream
rac.players.message
rac.players.announce
rac.bans.view
rac.bans.remove

rac.players:view
rac.players:kick
rac.players:ban
rac.players:stream
rac.players:message
rac.players:announce
rac.bans:view
rac.bans:remove
rac.entities:peds
rac.entities:vehicles
rac.entities:objects
rac.moderators:view
rac.moderators:edit
rac.moderators:whitelist

The second block is there because the ability ids are what an operator reaches for now, so a server.cfg written against the new names is recognised in the report as well. Being in the list is not a grant: none of the twenty-four opens anything.

Granting in-game access now

On the dashboard, under Management, open In-Game Moderators. Add the player's identifier, or use Moderator Access on their card in the Players List if they are connected, tick In-game staff, pick Moderator and tick the abilities they need. A change to a connected server takes effect in that session rather than at their next connect.

The rac lines in your server.cfg can stay or go as you prefer. Leaving them in grants nothing and costs nothing beyond the confusion of reading them later.

Clearing the world is checked twice

rac clear is the one in-game action two separate checks have to pass. First the game server reads the player's own row: they need entities:peds, entities:vehicles or entities:objects for every type they asked for, so rac clear all needs all three and a missing one answers You do not have permission for that. Then the request goes to the dashboard, which matches the player to a dashboard account by the discord: identifier their game reports and checks the same three World ticks on that account, one type at a time.

A player whose game reports no Discord identifier at all is refused, and so is one whose Discord is not linked to a dashboard account holding those ticks. The server console is not checked that way, but its path is off until you turn it on, and a resource calling the command through ExecuteCommand is refused before the dashboard is ever asked. See Commands.

What a whitelist exempts

No ace right switches a detection off, and neither does an ability on a staff row. A whitelist is the only thing that exempts a player, and it is a wide exemption rather than a narrow one. Raven keeps two named tables, one server-side and one client-side, and holds a third set of checks back by never running them at all while the flag is set. Together that is 46 detections a whitelisted player is not acted on for.

The two named tables are read at the moment Raven would act. The server table is checked against the detection that reported, so the action is dropped there; the client table is checked before the report leaves the player's game, so nothing is ever sent. One name, AntiBlacklistPedModel, is in both, which is why the two lists of 8 and 31 come to 38 distinct detections rather than 39.

The server-side table, 8 detections

The client-side table, 31 detections

This is the longer list, and it is the one the dashboard mirrors. lib/whitelistDetections.ts holds it name for name, gated per resource build, so the Moderators tab can tell an operator what their own server honours rather than what the newest build does. Read that file rather than a copy of the list, because it is kept in step with the Lua table on purpose and a list pasted into prose is not.

It covers the movement group apart from AntiSpectate and AntiSpeedHack, the fourteen vehicle-tampering checks, the weapon-state checks for ammo and reloading, godmode, ped manipulation, outfit swapping, the blacklist checks for animations and ped models, teleporting in a vehicle, isolated vehicle spawns, NUI tampering, the clipboard scanner and the screen OCR scan.

The eight checks that never run

These are not in either table. The client loop that would run them tests the whitelist flag first and returns, so no warning accrues and nothing reaches the server. The practical difference matters when you lift a whitelist: a detection in the tables above may have been counting warnings the whole time, where one of these starts from zero.

Where a whitelist comes from

A whitelist is that exemption and nothing more. It opens no menu, runs no command and carries no ability, which is what the staff row is for. Giving or taking one needs the In-Game Moderators Grant Whitelist tick on the dashboard, which is its own tick and is not included in the Edit one. See Admins and moderators for the list itself, and Server exports for the temporary one.