Permissions & Role Hierarchy

​

The rule that explains most permission issues

Discord enforces one hard rule for every bot, Petto included: a bot can never act on a member whose highest role sits above the bot’s own role in the server’s role list, no permission or admin setting overrides this. This applies to !ban, !kick, !mute, !role, and anything else that touches a member directly. Petto uses the server’s prefix; ! is only the default.

​

Fixing it

Server Settings → Roles, drag Petto’s own role up until it sits above every role you want it to be able to act on. It doesn’t need to be at the very top, just higher than its targets.

​

Bot permissions vs. channel permissions

Two separate things have to both be true:

1. Server-wide permissions: what Petto’s role is granted overall (Manage Roles, Ban Members, Manage Channels, etc.), set once in Server Settings → Roles.
2. Channel-specific overrides: a channel can deny Petto something it has server-wide, permission overwrites on a specific channel always win over the role-level grant.

A command failing in exactly one channel but working everywhere else is almost always #2, not #1.

​

Command-level permission requirements

Beyond what Petto itself needs, most config commands also require the member running them to have Manage Guild (or a more specific permission like Ban Members for !ban). This is Discord’s own permission system, checked by Petto for prefix commands.

​

Petto command levels

The dashboard’s Permissions page and !permission expose an additional optional layer. Create groups from level 0 to 100, assign users or roles, then set a required level on a command. The highest matching group level wins. This layer never replaces Discord permissions or hierarchy; it only adds a configurable staff gate. See Command permissions for the full prefix-only command reference.

​

Where this shows up