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
  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
  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
  Toggle the modules they should have

  The editor lists every available module with an on/off switch. Flip on the modules this person or role needs. Each module shows how many commands it contains and can be expanded to fine-tune them.

• 4
  Fine-tune individual commands (optional)

  Expand a module to see its commands. Each has a three-way control — Inherit (follow the module grant), Allow (force on), or Deny (force off). Use these only when you need an exception; most setups never touch them.

• 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.

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:

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 /mod warn, /mod timeout, /mod purge and /channel slowmode (inherited from the module) but is blocked from /mod ban, /mod 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 /mod 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:

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.

• 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.

• 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.

• 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.

• 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.

• 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.

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, /leaderboard, /setbg, /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.