Skip to main content
Command policies control where Bloom’s commands work and who can use them. A rule says allow or deny, names what it applies to, and names where it applies. You can turn one command off in one channel, restrict a whole category to a role, or shut everything down outside a bot channel.
Every command here needs Administrator.

​
How a rule is decided

When someone runs a command, Bloom checks the rules in this order:
1

Protected commands always run

A short list of commands can never be blocked, so a bad rule cannot lock you out of fixing it.
2

Administrators always pass

Policies never apply to administrators or the server owner. Test your rules with an ordinary account.
3

The most specific rule wins

Bloom scores every rule that matches and applies the narrowest one.
4

A tie goes to deny

When two equally specific rules disagree, the denial wins.
Specificity is decided by where the rule applies before anything else: A channel rule always beats a server rule, whatever else the two rules say. Within the same place, a rule naming one command beats a rule naming a category of commands, which beats a rule naming everything. A rule for a role beats a rule for everyone.
This means the usual pattern works the way you would hope: deny everything server wide, then allow what you want in the channels where you want it.

​
Commands that cannot be blocked

commandpolicy, disablecommand, enablecommand, restrictcommand, unrestrictcommand, their short aliases, plus setprefix and help.
This is your way back. If a rule locks a channel down harder than you meant, !commandpolicy rules and !commandpolicy reset still work there.

​
Setting rules

​
Administrator
Blocks something. Aliases: cmdpolicy, cmdrules.
  • Without a channel the rule covers the whole server.
  • Without a role the rule covers everyone.
  • !commandpolicy deny all #general turns every command off in one channel.
  • !commandpolicy deny category:fun turns off a whole category server wide.
​
Administrator
Permits something, overriding a broader denial.
  • !commandpolicy allow ping #general re-enables one command in a channel you had closed off.
​
Administrator
Limits something to one or more roles in a single step. Bloom writes a denial for everyone and an allowance for each role you name, replacing any existing rules for that target.
  • At least one role is required.
  • !commandpolicy restrict category:music @DJ #music leaves music commands working only for DJs, only in that channel.

​
Checking and undoing rules

​
Administrator
Lists your rules, each with an ID. With a channel it shows only the rules that affect that channel. Alias: list.
​
Administrator
Reports how many rules affect a channel, as a quick check before you add another.
​
Administrator
Answers whether a command would run, for the channel and roles you name, and shows which rule decided it. Use it instead of guessing.
  • !commandpolicy test ping #general explains the outcome for that combination.
​
Administrator
Removes rules. Aliases: remove, delete. Takes a single rule ID from commandpolicy rules, or clears everything at one scope.
​
Administrator
Lists every command category with how many commands it holds, which is how you find the right name for category:.

​
Shorter commands for common cases

These are shortcuts into the same system. A rule made with disablecommand is an ordinary policy rule, and shows up in commandpolicy rules like any other.
​
Administrator
Turns a command off, in one channel or across the server. Aliases: dcmd, disablecmd.
​
Administrator
Limits a command to a role. Aliases: restrictcmd, rcmd.

​
Worked example

To make a bot channel the only place general commands work, while leaving moderators unrestricted everywhere:
Lock commands to one channel
The first rule closes the server. The second beats it in #bot-commands because a channel rule outranks a server rule. The third beats it for moderators because a role rule outranks an everyone rule at the same scope. Confirm it with !commandpolicy test ping #general before you walk away.

​
Troubleshooting

Administrators and the server owner bypass every policy. Test with an account that holds no administrator permission.
A more specific rule is winning. Run !commandpolicy test <command> #channel to see which rule decided the outcome, then narrow your allow rule to match or remove the rule that is beating it.
When two rules are equally specific, the denial wins. Make the allowing rule more specific, for example by naming the channel or the role rather than the whole server.
It is on the protected list, which exists so a rule cannot lock you out of the commands that fix rules.
Use the exact command name rather than an alias, and !commandpolicy catalog for the category names that category: accepts.
The policy commands still work everywhere. Run !commandpolicy reset #channel in the affected channel, or !commandpolicy reset server to clear the server wide rules.

Fake permissions

Granting access to commands rather than taking it away.

Permissions and hierarchy

The permission checks that run after a policy allows a command.

Commands not responding

Working out whether a policy is why nothing happened.

Command aliases

Custom names for commands, which policies apply to as well.