Permissions and capabilities

Aethor’s permission system asks who may perform a specific action. It does not give someone a vague “staff” switch. You can let a support role manage tickets without letting it change suggestions, or let a suggestion team resolve ideas without giving it Discord’s broad Manage Messages permission.

You manage these rules in the dashboard. Pick a server, then open Settings → Permissions.

Start here🔗

Keep these four rules in mind:

1. A capability is one action, such as “change a suggestion’s state” or “publish button roles”.
2. A group rule controls a useful bundle of related actions. Most servers only need group rules.
3. An action override changes one capability without changing the rest of its group.
4. A role rule replaces the normal Discord permission requirement. It is not added on top of it.

That last point matters. Suppose Suggestions · Moderators normally requires Manage Messages. If you change the group to Only selected roles → @Suggestion Team, then:

• a member of @Suggestion Team can use those actions without Manage Messages;
• someone with Manage Messages but without @Suggestion Team no longer qualifies through that permission;
• the server owner and Discord administrators still retain access;
• Aethor’s own Discord permissions and premium requirements still apply.

The permission screen🔗

The Rules tab is where you decide who gets access. Features are divided into 15 groups, such as Suggestions · Members, Suggestions · Moderators, Tickets · Managers, Autoresponders · Moderators and Anti-invite · Moderators.

Each group shows its current audience, how many actions it contains, the slash commands it affects, and whether any action has its own override. Expand a group to inspect every capability before changing it.

The Access tab answers the opposite question: what can this person or role actually do? It checks the same server-side rules used by the dashboard, slash commands, buttons, menus and modals.

Which guide do you need?🔗

What the three default levels mean🔗

When a group says Discord permissions, it uses the following built-in rule:

Level	Who qualifies by default
Members	Any current member of the server.
Moderators	Members with Discord’s Manage Messages permission. The soft-ban capability is a deliberate exception and requires Ban Members.
Managers	Members who have Manage Channels, Manage Messages and Manage Server. All three are required.

These labels describe Aethor’s defaults; they do not create or edit Discord roles.

Checks that a role rule never bypasses🔗

A role grant only replaces the actor’s normal Discord permission test. It cannot make an impossible action possible. Aethor still checks:

• that the person is currently a member of the server;
• that Aethor itself has the Discord permissions needed to perform the action;
• that the server has premium when the action is premium-only;
• that the server, role and target still exist;
• that current Discord data is available;
• ownership and hierarchy rules that belong to the action itself.

For example, granting Button roles · Managers to a team does not let Aethor assign a role above Aethor’s highest role. Granting Anti-invite · Managers does not unlock Anti-invite on a free server.

Access that cannot be delegated away🔗

The server owner and members with Discord’s Administrator permission always keep actor access. This is the recovery path if a rule is too restrictive.

The ability to view and change the permission system itself is stricter: guild.permissions.read and guild.permissions.update always use the manager rule, which requires Manage Channels, Manage Messages and Manage Server. They cannot be placed behind a custom role rule. Aethor ignores any stored override that tries to change those two capabilities.

Suggestion authors also keep two narrow owner actions: editing their own suggestion and deleting their own suggestion. A Suggestions · Moderators role rule controls staff use of those actions; it does not take those author actions away.

Rules apply everywhere🔗

The same capability check protects:

• dashboard pages and API requests;
• Discord slash commands;
• buttons, select menus and modal submissions;
• suggestion and configuration actions that continue after the first click.

Discord still decides whether a slash command is visible in its command picker. That is a separate presentation layer, which is why role-based servers should read Discord command visibility and usually enable the sync.