Permissions

A permission is an in-game capability — a string key like admin.kick_player or economy.set_money that the game checks before letting a player perform a sensitive action. You grant permissions to groups, and players inherit them through group membership.

How a permission check flows

Player triggers an action
        │
        ▼
Game asks: "Does this player have permission X?"
        │
        ▼
Player is in Master? ──► YES → allow (Master implicitly has every permission)
        │ NO
        ▼
Look up player's groups in this environment
        │
        ▼
Any of their groups have the permission row? ──► YES → allow
        │ NO
        ▼
Deny

So a permission is granted when either:

• The player is in the Master group (bypass), or
• The player belongs to a group that has an explicit grant row.

Where to manage them

1. Open your project → Environments → pick the env → Permissions tab.
2. The page lists every grant in this environment as a row: <Group> → <permission-key>.
3. Use Add permission to grant a new key to a group, or click the trash icon on a row to revoke.

The catalog of available permissions is determined by your gamemode + every enabled addon in this environment. If you install a new addon, the permissions it declares automatically become grantable.

The permission key structure

Permission keys follow <ident>.<name>:

emrald.darkrp.admin.kick_player
emrald.darkrp.economy.set_money
yourorg.hitman.target.assign

• Ident — the package that declared it (gamemode or addon).
• Name — lower_snake_case action identifier.
• Category — used purely for UI grouping in the catalog.

The full key is what the game uses internally; the panel just splits it visually so you can browse by package and category.

Grant a permission

1. Click Add permission.
2. In the dialog:
   • Group — which group receives the capability.
   • Permission — pick from the catalog (filtered by package and category).
3. Click Add. The grant row appears in the table and applies live.

Revoke a permission

Click the trash icon on the row, confirm. The grant is removed and applies live.

Master is special

The Master group does not need explicit permission rows — it ignores the permissions table entirely and is granted everything by the game-side check. You won't see Master rows in the Permissions tab; that's by design.

This means:

• Adding a new addon → Master can do everything it declares, immediately, without you granting anything.
• Removing a permission row from a custom group does not affect Master.
• If you put someone in Master, they have every capability in the gamemode and every addon, present and future. Use it sparingly.

Inheritance

Permissions follow the environment inheritance chain, but materialize per-environment — they don't fall back. A grant added in Production shows up in Staging's Changes view as a difference; merge it across to keep envs in sync.

Common permission patterns

A typical DarkRP-style staff hierarchy might look like:

Master       ─►  (everything, implicit)
Admin        ─►  admin.kick, admin.ban, admin.cleanup, economy.set_money
Moderator    ─►  admin.kick, admin.warn, chat.mute
VIP          ─►  (no admin permissions — just gameplay perks)
Default      ─►  (nothing — base player, no admin power)

Build this in the Permissions tab by creating the four custom groups in Groups, then granting the appropriate keys to each.

Gamemode switch

When you switch a project's gamemode, all permission grants in every environment are wiped. The new gamemode declares its own catalog and you re-grant from scratch.

Next steps

• Groups — manage the roles you're granting permissions to
• Changes — see which permissions differ between environments