Permission Reference

A permission is one thing a person may do in your project, such as ban a player, reply to a report or change settings. A role is a ranked bundle of permissions, and every member has exactly one role. The table at the bottom of this page lists every permission, in the same groups as the Roles screen: its label, its technical name and what it allows. This page explains how permissions combine, which is the part the table cannot show.

You set permissions on Settings > Roles, described in Roles and Permissions.

What Decides Whether Someone Can Do Something

Holding a permission is the first test, not the only one. For a staff member to use something, all of these must be true:

1. Their role includes the permission. The project owner counts as holding every permission.
2. The feature that governs it is on. Many permissions belong to a feature on Settings > Features. While the feature is off, the permission is withheld from everyone. See Features and Modules.
3. Your framework and resource can do it. Some actions need something the game server has to provide. See Capabilities below.
4. For the in-game menu, the menu is on and the account is linked. See In-Game Permissions below.
5. For team permissions, rank allows it. You can only manage people and roles ranked below you.
6. The plan has room. Limits such as staff seats and roles can still refuse an action. See Plans and Limits.

When something is missing, the panel tells you which: “Your role does not include this.” for a role, or “{feature} is turned off for this project (Settings > Features).” for a switch.

Roles and Rank

A member has one role, and their permissions are exactly that role’s permissions. Permissions from other roles never add up.

Roles are ranked. Rank 1 is the highest, and the Roles screen lists roles highest first. Higher roles manage the roles and people below them:

• Manage Roles lets someone create roles and change what lower roles can do.
• Manage Members lets someone invite, remove and change the role of lower-ranked staff.
• Nobody can change the role or the permissions of a role at or above their own, and nobody can change their own role.
• Nobody can hand out a permission they do not hold themselves. The panel says “You don’t hold this permission yourself, so you cannot grant or remove it.” You can only give someone a role if you hold every permission the role carries.

New roles start at the bottom rank with no permissions. A new project starts with three ordinary roles that you can edit or delete: Admin, which holds everything except Manage Server Link, Edit Settings and Advanced Settings, Moderator and Support.

The Owner

The project owner holds every permission and outranks every role. Some things no role can be given:

• the Plan, Payments and Delete Project screens;
• running the guided setup;
• importing a txAdmin backup under Settings > Import from txAdmin;
• the In-Game Menu and Player Reports switches on the Features screen;
• stopping other staff members’ Player Monitor streams.

Moving a Discord server that is already connected to another project is not decided by a MonoAdmin role. Only the Discord server’s own owner on Discord can move it.

The owner is not above the switches. A feature that is off is off for the owner too. And if MonoAdmin suspends a project, every permission is withheld, the owner’s included, until the project is restored. The owner also cannot leave the project: delete it in Settings instead.

Feature Switches

Switching a feature off withholds its permissions from every role, the owner included, in the panel and in game. Switching it on gives back only what roles already grant. It can take away but never give. MonoAdmin can also switch some features off for a project. Neither a project’s switch nor MonoAdmin’s can give back what the other took away. The table on the Features page shows which feature governs which permission. A permission no feature governs, such as View Players, is always available to a role that holds it.

Capabilities of the Framework and the Resource

A permission lets a role ask. The game server has to be able to do it. Which things it can do depends on your framework and on the version of the resource running on it.

• Standalone servers have no framework data. Money, Items and Jobs actions, Character Data and Owned Vehicles are not available on them, and neither are the matching switches.
• Character Data and Owned Vehicles need ESX, QBCore or Qbox with oxmysql. Edit Gang exists only on QBCore and Qbox.
• A resource that is older than a feature does not offer it yet. The panel then says the resource “doesn’t support this yet” and asks you to update it.

Where the framework cannot do something, the control is hidden or disabled, and an attempt answers “This isn’t available for this server’s framework or resource version.” While your server is online, the panel uses what the resource says it can do. While it is offline, the panel shows everything your framework could offer, so pages do not vanish every time the server restarts.

In-Game Permissions

The In Game group covers what only the in-game menu can do: opening it, noclip, invisibility, god mode, super jump, spectating, seeing player names and blips, and the Game World Editor. Everything else in the menu uses the same permission as on the web. Warning a player from the menu needs Warn, healing needs Heal, and so on.

The menu works only when all three of these are true:

• the project owner switched the In-Game Menu on in Settings > Features;
• the staff member’s role includes Open the In-Game Menu;
• the staff member linked their game account in Settings > My Membership.

Each action is checked again every time it is used, and staff powers in game end about a minute after the link to MonoAdmin is lost. The in-game menu never shows player IP addresses, whatever the role: View Player IPs applies to the web panel only. See Turn On and Open the Menu.

Seeing Without Doing

Many permissions come in pairs: one to see and one to act. A role with View Reports and no Manage Reports reads reports: “You can read reports. Replying and changing them needs the Manage Reports permission.” A role with View Settings and no Edit Settings sees settings screens locked. Pages and dashboard cards appear only for members who hold the permission that opens them, so a role without a permission also does not see the page it belongs to.

All Permissions

Players

Player Actions

Fun Actions

Punishments

Whitelist

Reports

Server

Player Monitor

In Game

Owned Vehicles

Character Data

Insights & Logs

Team & Settings