Configuring Permissions

Every module in GiselleBot is authorized separately. This guide walks through the practical setup: deciding who needs what, applying it from the dashboard, and confirming that a normal member gets the result you expect.

The Permissions System reference explains the four permission layers in detail. Read that page when you need to understand why a check failed; use this page when you just need to configure the checks.

Before you start

You need Manage Server in the Discord server. That permission also lets you bypass module authorization yourself, which is why testing as a manager is not enough - use a second account or a member you trust for the final check.

Remember that module authorization is per module, not per command. Authorizing a role for the moderation module gives it every command in that module (/warn, /ban, /case, /restrict, ...). There is currently no per-command switch on the dashboard.

Step 1: Decide the access policy

Write down the answer to three questions before opening the dashboard:

Which modules should ordinary members use?
Which modules should only the moderator team use?
Which modules should only server managers use?

A common starting point is:

Keep utility, alarms, social ranking and the game integrations open to everyone.
Give the moderator role the moderation and automoderator modules.
Keep administration, permissions, forms, reddit and rss manager-only until there is a reason to open them.

The Default Module Permissions section lists exactly which modules start open and which start manager-only.

Step 2: Open the Command Permissions page

On the dashboard, choose your server, then open Command Permissions. The page lists every module with its current state.

Each module has three things to configure:

Enabled or disabled - a disabled module cannot be used by anyone, including server managers.
Roles and users - the members who may use the module. Server managers always pass this check.
Channel overrides - an optional whitelist or blacklist that applies to non-managers.

Note

The permissions module itself cannot be disabled. This is deliberate: it prevents a bulk change from locking every manager out of the page that would fix it.

Step 3: Authorize roles and users

Open a module and add the roles or individual users that should have access. Prefer roles over individual users - a role keeps working when people join or leave the team.

For the moderation module, this is the step that designates your moderator team. The The Bot and Moderation guide covers the rest of that setup, including rules, point values and log channels.

Do the same for every module you want to open up. If you are unsure, leave the module manager-only for now and revisit it after the first week.

Step 4: Add channel overrides where they help

Channel overrides limit where a module can be used. They only apply to non-managers, and they are checked before role authorization.

Whitelist - the module only works inside the selected channels.
Blacklist - the module works everywhere except the selected channels.

For example, you might whitelist utility commands to a #bot-commands channel, or blacklist the moderation module from public channels. Server managers ignore these overrides.

Step 5: Apply the same settings to several modules

Repeating the same roles, users and channels for every module is tedious and easy to get wrong. The dashboard has two bulk options:

From one module's permissions page, Apply to other modules... copies the current settings (saved or not) onto any other modules you select.
From the module list, select several modules' checkboxes and choose Configure selected... to edit them together, starting from the first selected module.

A bulk apply can never disable the permissions module - if the batch includes "disabled", that one module stays enabled.

Step 6: Test as a normal member

Ask a member who is not a server manager to run one command from each module you opened. Then check these cases:

The command is missing from Discord's picker. That is Discord's own Integrations setting, not the dashboard. Check Server Settings -> Integrations -> GiselleBot.
The command appears but the bot says the member is not authorized. The member is missing module authorization, or the module is disabled, or a channel override blocked the channel.
The command runs but stops with a Discord permission error. The command has its own permission check on top of module authorization - for example, /restrict needs Manage Roles for most of its subcommands.

The How Permission Checks Work section maps each of those messages to the layer that produced it.

Warning

Do not use a server manager account for the final test. Managers bypass module authorization and channel overrides, so a command that works for you may still be blocked for everyone else.

Keeping it current

Review the Command Permissions page when the moderator team changes, when you add a module, and after any bulk edit. A role that was removed from the Discord server can leave a module looking open when nobody can actually use it.