Permission Manager

A custom, always-on permission layer that fully replaces Discord's native permission checks for Azra's commands and dashboard pages.

The Permission Manager lets you answer two questions for every member and every role in your server:

Every time someone runs a command or opens a dashboard page, Azra resolves their effective access from your grants.

The three kinds of command#

All surfaces of a command are treated as one#

A command can be invoked several ways — a slash command, a text/prefix command, a right-click context menu, or a message button. Azra groups every surface of the same capability under one action, so a grant or a denial always spans all of them:

Under the hood#

Grants are stored per-server as two small tables — module grants and per-command overrides. The set of modules and commands (the "catalogue") is defined in Azra's code, so it always matches the bot exactly; the database only stores your grants:

Resolution is cached for a few minutes and refreshed instantly when you save a change, so grants take effect within seconds. If Azra can't read the permission data (e.g. a brief database hiccup), it fails closed — access is denied rather than accidentally opened.

Everything is managed from the dashboard's Permissions Manager page — no commands required.

1. 1

   Open the Permissions Manager

   Go to Dashboard → your server → Permissions Manager (the key icon in the sidebar). It's visible to the server owner, Discord admins, and anyone you've given the Manage Permissions capability.

2. 2

   Pick a user or a role

   Use the Users tab to search a member by name, or the Roles tab to choose a role. Roles are almost always the better choice — grant a role once and every member who has it inherits the access.

3. 3

   Switch on the modules they should have

   Every module is its own card with a single Allow all permissions switch. Turning it on grants the whole module — its commands and its dashboard page — and allows every command inside it. Nothing is written until you save.

   The tabs above the cards only change what you are looking at: Discord Access Moderation keeps the modules Discord also has permissions for (each shown in full, with the rows Discord cannot express marked Azra only), and Azra Dashboard Access keeps everything Discord has no permission for. A card lists the same commands on every tab.

4. 4

   Fine-tune individual commands (optional)

   Every command inside a module is listed in its card, each with its own Allow / Deny pair — nothing is hidden behind an expander. Deny carves an exception out of a module you granted (a moderator who may kick but not ban); Allow on its own hands out a single command without the module. A command with neither picked follows its module's switch, and re-clicking the side you picked clears it. Most setups never touch these.

5. 5

   Save your changes

   Edits are staged in a sticky Save changes bar at the bottom — nothing is written until you click Save (or Discard to revert). This lets you set up a full staff role in one pass. You'll be warned before leaving with unsaved changes.

   A big edit is a sequence of writes, so a progress panel floats in the bottom corner while it runs: how many of how many changes are saved, what is still pending, and a percentage bar that moves as each one lands. Minimize it (the minus button) to carry on working elsewhere in the dashboard — the save keeps going, and the small pill it leaves behind shows the same progress. Click that pill to reopen the details. When everything has landed you get a clear success message; if any change is refused, the panel names it, says why, and offers Retry failed — a success message only ever appears once every change is saved.

Removing all of one person grants at once#

Two separate things: who is allowed to manage permissions, and what Discord permissions the bot itself still needs.

Who can manage permissions#

What the bot itself needs#

The Permission Manager decides who may ask Azra to do something. Azra still needs its own Discord permissions to actually carry it out:

Grants are attached to a "subject" — either a role or a specific user. A member's access is the union of both.

How a member's access is combined#

A member's effective permissions are the union of their own user grants plus the grants on every role they hold. If any of those sources grants a module or allows a command, they have it — unless something explicitly denies it (see Inheritance & Overrides).

Each feature of Azra is a module. Granting a module unlocks both its bot commands and its dashboard configuration page.

Some modules are command-driven, some are configured purely from the dashboard, and some are both. A module grant covers whichever surfaces the module has:

What each module unlocks#

Paused modules#

Command overrides are how you make exceptions to a module grant. Understanding the precedence is the key to the whole system.

The three states of a command#

Resolution order (highest priority first)#

When a member runs a command, Azra checks, in order:

Worked example#

Suppose your @Trial Mod role is set up like this:

Subject: role @Trial Mod
  module "moderation"     = granted        (all mod commands inherit → allowed)
  command "ban"           = Deny           (override: force off)
  command "kick"          = Deny           (override: force off)
  command "lockdown"      = Deny           (override: force off)

A member with only @Trial Mod can /warn, /timeout, /purge and /slowmode (inherited from the module) but is blocked from /ban, /kick and /channel lockdown — on every surface, including the right-click menus. Give them the senior @Mod role later (no denies) and they immediately gain the full set, because that role's grant has nothing subtracting from it.

Allow without the module#

The reverse pattern hands out a single command with no module access:

Subject: user @Helper
  module "moderation"     = not granted
  command "warn"          = Allow          (override: force on)

@Helper can use /warn (and !warn) but nothing else in moderation, and never sees the Moderation dashboard page (that needs the module grant).

You can safely let trusted staff manage permissions themselves — Azra enforces guardrails that stop them from escalating their own power.

Grant a staff member (or role) the manage_permissions module and they can open the Permissions Manager. To prevent privilege escalation, a delegated manager (anyone who isn't the owner or a Discord admin) is bound by these rules — all enforced on the server, not just hidden in the UI:

Azra can read the permissions your roles already have, and from there you choose one of two ways to keep them: stay in step with Discord, or have Azra own the moderation permissions it supports.

Step 1 — Import the permissions the server already has#

On the Permissions Manager page, press Import Permissions from Discord. Azra reads every role and proposes the grants that match it — a role that can kick but not ban becomes exactly that, and nothing is written until you confirm the preview. Roles that cannot be imported are listed with the reason (the @everyone role, integration-managed roles, roles above Azra's own, and anything with Administrator, which already has everything).

Step 2 — Choose how Azra and Discord work together#

As soon as the import finishes, you are given two options. They are the only two supported ways to run: pick the one that matches who you want holding the permission.

It is previewed, confirmed and undoable#

Removing a permission from a role is not something Discord can undo — it keeps no record of what a role's permissions used to be — so Azra does not treat it as a side effect. Choosing Use AZRA Permissions Manager saves the mode and then opens the removal preview: you see every role and every permission that would be taken, then confirm again. Before anything is changed, Azra saves what each role had. If you change your mind, Undo last removal on the same page puts the permissions back.

What cannot be imported#

Discord has no equivalent of warnings, the numbered case record, escalation ladders, tickets, forms, giveaways or levelling. Nothing can be imported for those, so grant them in the editor above — the import shows you the list rather than quietly covering part of your setup.

Recipes you can copy. All of these use role grants — set the role up once and assign it to your team.

A few habits that keep permissions simple and secure as your server grows.

1. Grant to roles, not people

   Attach access to a "Moderator" / "Host" / "Support" role and assign the role in Discord. It scales, self-documents, and updates automatically as your team changes. Reserve user grants for genuine one-offs.

2. Grant the whole module, subtract with Deny

   It's cleaner to grant moderation and deny the two commands a junior shouldn't touch than to allow ten commands one by one. Because deny always wins, the carve-outs are guaranteed.

3. Hand out Manage Permissions sparingly

   It's the most powerful capability. Give it only to your most senior staff, and remember delegated managers are still boxed in by role hierarchy and can only re-share modules they already hold.

4. Mirror your Discord role hierarchy

   Keep senior staff roles positioned above junior ones in Discord. Delegated managers can only manage roles below their own, so a clean hierarchy makes delegation intuitive.

5. Review the subjects list periodically

   The "Members & roles with grants" panel is your at-a-glance audit. Clear anyone who's left the team, and confirm no user grant has quietly outlived its purpose.

The usual culprits when access doesn't behave as expected.

Symptoms and fixes#

Quick answers to the most common questions.

Does this replace Discord permissions?#

For Azra's gated commands and dashboard, yes — Azra ignores Discord permissions entirely and uses only your grants. Your Discord permissions still govern everything else in your server (who can send messages, manage channels manually, etc.).

Can I turn the permission system off?#

No — it's always enforced. There's no per-server switch. On a fresh server, grant your staff the modules they need so they don't lose access; the owner and Discord Administrators always retain full control in the meantime.

Do Discord admins need to be granted anything?#

No. A member with the Discord Administrator permission is treated like the owner — they have every module by default and can run any gated command with no grant (a deny can't block them either). Grants exist for handing precise access to non-admin staff. Note that Manage Server on its own doesn't grant automatic command access — only full Administrator does — though Manage Server is still enough to open and configure the dashboard.

What can new members / regular users do without any grant?#

Only the public, self-service commands: /rank, /profile, /rewards, /leaderboard, /setbg, /whois, /ping, /help, the !prefix viewer, and entering giveaways. Everything else needs a grant.

If I grant a module, does that give dashboard access too?#

Yes. A module grant unlocks both the module's bot commands and its configuration page on the dashboard. That's why a config-only module like welcome or analytics is worth granting even though its dashboard page is the main way to use it.

User grant and role grant conflict — which wins?#

They combine (union), and then the deny rule applies: a Deny on either the user or any of their roles wins over any allow or module grant. Otherwise, an allow/grant from any source is enough.

Can a staff member grant themselves more power?#

No. A delegated manager can only grant modules they already hold, can't touch manage_permissions, and can't manage roles at or above their own. Only the owner or a Discord admin can hand out the top-level capability.

Do denies cover right-click and text commands too?#

Yes. Overrides apply to the whole capability, so denying ban blocks the slash command, the !ban prefix command, and the Quick Ban context menu together — no surface can be used to bypass it.

What happens to grants if I remove a role or the person leaves?#

Role grants simply stop applying to anyone who no longer has the role — the grant stays on the role for whoever keeps it. If you delete a role in Discord, its grants are cleaned up. User grants persist until you clear them from the subjects list.