Documentation menu

The permission model

A closer look at how Aurora combines Discord permissions, permission groups, hierarchy and command rules.

Every command, button, form and dashboard change goes through one permission evaluation. It runs on the server, in this order of questions:

  1. Bot owner only? Operator commands such as /aurora health are limited to the bot owners configured by the operator. If none are configured, nobody can use them.

  2. In a server? Commands that act on a server are refused in direct messages.

  3. Command enabled and allowed here? Disabled commands, channel rules and role rules apply. The server owner and Discord Administrators are never locked out, and /config and /help cannot be disabled.

  4. Does the person have the Discord permission the command needs, if any?

  5. Does the person hold the Aurora group the command needs, if any? ADMINISTRATOR satisfies every group, and MODERATOR also satisfies HELPER. The server owner and Discord Administrators pass the group check.

  6. Does Aurora itself have the permission it needs for the action? If not, the command says what is missing.

  7. Hierarchy: for actions on a member, Aurora refuses the person themselves, the server owner, Aurora, and anyone whose highest role is equal to or above the actor's or Aurora's.

Buttons and forms#

A button is checked against its handler's own requirement and the clicker's live roles, never against the button's id, so a forged or leftover button cannot widen access.

The dashboard#

The dashboard uses the same evaluation, with live Discord facts for each request. The list of servers shown after sign-in is only a hint for the picker.