Fake permissions
Give a role a permission that only exists inside Righteous, so a moderator can run bot commands without holding anything in Discord.
A fake permission lets a role pass Righteous' own permission checks without holding that permission
in Discord. Grant BAN_MEMBERS as a fake permission and the role can run
,ban, and nothing else. Discord's own ban button stays greyed
out, because Discord was never told anything.
Only the server owner can hand these out. Every ,fakepermissions subcommand is Server Owner only,
so a permission you granted through this system can never be used to grant more of them.
Overview
Why you would want one
The usual reason is that a moderation role needs to use the bot without being able to use Discord.
A trial moderator who holds real Ban Members can ban from the right-click menu, from a phone, and
from any other bot in the server. The same person holding a fake BAN_MEMBERS can only ban
through Righteous, where every action is logged, rate-limited, hierarchy-checked and reversible
from a punishment history.
It is also the answer to "this command needs Manage Server and I am not giving anybody Manage Server". Grant the fake permission instead, and the command opens without the Discord permission opening with it.
How the bot decides
Every gated command declares the permissions it needs. When somebody runs one, Righteous checks their real Discord permissions first, and only then looks at the fake-permission table for anything still missing. Two details matter more than they look:
The match is on the permission itself, not on the word you typed. Discord has renamed
permissions over the years and the bot keeps the old spellings working, so a row stored as
MANAGE_CHANNEL satisfies a command that requires MANAGE_CHANNELS. Grant the current name
(,fp type prints it) and old rows
keep working on their own.
A fake ADMINISTRATOR behaves like a real one, on the bot. It satisfies every permission check
Righteous makes, not just commands that literally ask for ADMINISTRATOR. That mirrors how Discord
treats a real administrator, and it is the reason to be careful: granting fake ADMINISTRATOR opens
every permission-gated command in one line.
Fake permissions are server-wide, never per-channel
There is no way to grant one in a single channel. A role granted MANAGE_MESSAGES on the bot has
it everywhere the bot works. If you need the narrower thing, use Discord's own channel overwrites
and do not grant the fake permission at all.
Setting it up
Grants are stored per role, not per member, so a member gains and loses them by gaining and losing the role.
Grant a permission to a role
,fp add takes a role and one
permission name. Name the role by mention, by ID, or by a single word from its name: the bot
matches the first role containing that word.
Syntax
,fakepermissions add <role> <permission>
Example
,fp add @Moderator BAN_MEMBERS
Permission names are the bot's own spelling (SCREAMING_CASE, underscores, no spaces) and are
not case-sensitive on input. One permission per run; grant a second by running it again. A
permission the role already has is refused rather than stored twice. The slash form offers the
names as autocomplete, which is the easiest way to avoid a typo.
Take a permission back
,fp remove is the exact
inverse, and takes the same two arguments.
Syntax
,fakepermissions remove <role> <permission>
Example
,fp remove @Moderator BAN_MEMBERS
The change applies immediately: there is no cache to wait out and nobody needs to leave and rejoin.
See what you have granted
,fp list prints every
role-and-permission pair in the server, paginated.
Syntax
,fakepermissions list
To answer the question from the other end (what does this member actually have), use
,permissions view. It lists real permissions
and fake ones separately, in the same spelling this page uses, and says in its footer when a
member holds fake ADMINISTRATOR.
See the valid permission names
,fp type prints every name the
bot accepts. It is generated from the same list that validates a grant, so it can never drift
from what ,fp add will take.
Syntax
,fakepermissions type
Clear every grant at once
,fp reset empties the whole
table for the server. It is not scoped to one role, and there is no undo, so it asks for the
word confirm first, and tells you how many grants it removed.
Syntax
,fakepermissions reset confirm
Example
,fp reset confirm
This clears every role, not the one you were looking at
There is no per-role form. If you want to take one permission off one role, that is
,fp remove. Reaching for
reset when you meant remove is how a whole staff configuration gets deleted in one command.
Recommended setup
There is no preset. These are the grants that match how most servers actually split their staff, and each row is a starting point to trim rather than a rule.
| Staff level | Grant | Opens |
|---|---|---|
| Trial moderator | MANAGE_MESSAGES | ,clear and the message-side moderation commands |
| Moderator | MANAGE_MESSAGES, MODERATE_MEMBERS, KICK_MEMBERS | ,timeout and ,kick on top of the above |
| Senior moderator | BAN_MEMBERS, MANAGE_ROLES | ,ban, and handing out the roles the bot manages |
| Manager | MANAGE_GUILD | Server-level settings: the welcome message, the trap channel, most of the server-tools commands |
| Nobody | ADMINISTRATOR | Every permission-gated command in one grant, including ,config and ,log. Use it deliberately or not at all |
Grant the narrowest thing that opens the command somebody actually needs. ,permissions view on a
member is the quickest way to check you did.
What a fake permission will not do
This is the part that surprises people, and every item below is deliberate rather than a gap.
It does nothing outside Righteous
Discord is never told. The member cannot ban from the right-click menu, cannot see a channel they could not see before, and gets nothing at all from any other bot in the server. If the answer to a problem is "they need this permission in Discord", a fake permission is the wrong tool.
It cannot reach the server-owner commands
A handful of commands are gated on being the actual server owner rather than on a permission, and
that gate is not grantable: not by ADMINISTRATOR, not by anything. It covers the server's own
security tooling: ,antinuke and every rule under it,
,stripstaff,
,staff, and ,fakepermissions itself.
That is the whole reason it exists. If anti-nuke were gated on ADMINISTRATOR, somebody holding a
fake ADMINISTRATOR could turn off the protection that is meant to contain them.
It does not make anybody immune to the filters or the trap
Message-filter and trap channel
immunity is a bypass list, not a permission. The exempt set is the server owner and whoever you
added with ,filter whitelist add or
,trap whitelist add, nothing else. A role holding
fake ADMINISTRATOR still gets its invites deleted and still walks into the trap.
Gating punishment is a different question from gating command access, and answering it with the same table would hand filter immunity to every fake-permission role the moment it was granted.
It does not let anybody outrank anybody
Every command that acts on another member runs two more checks after the permission one: the target must not be the server owner, and the target's highest role must sit below the caller's. Neither reads the fake-permission table.
So a member whose only power is a fake ADMINISTRATOR (no real Discord permissions, a role at
the bottom of the list) can run the moderation commands and will be refused by every one of them
the moment they aim at somebody above them. The permission opens the command. The hierarchy decides
who it may be pointed at.
Why gated commands are still visible
Righteous does not hide slash commands from members who cannot use them. Every command shows in the
/ picker for everybody, and a member without the permission gets a private refusal naming what
they are missing.
That is a deliberate trade. Discord's own way of hiding a command checks a member's real permissions before the bot is ever asked, so a fake permission would be evaluated too late to matter. The whole feature would silently stop working on slash commands. A visible command that says no is the cost of a fake permission working at all.
Common issues
"Invalid Permission". The name is not one the bot accepts. Run
,fp type and copy the spelling, or
use the slash form and let autocomplete fill it in.
"Invalid Role". The bot matched nothing. Mention the role or paste its ID: a role name with a space in it only matches on its first word.
"Fake Permission already exists for this role". That role already has it. Run
,fp list to see everything granted.
A member with a fake permission still can't run the command. Check three things in order: they
hold the role, the command is not one of the server-owner-only ones above, and they are not being
refused by hierarchy for the member they aimed at. ,permissions view on them settles the first.
A fake ADMINISTRATOR opened more than expected. It satisfies every permission check on the
bot, exactly as a real administrator does. Remove it and grant the specific permissions instead.
Nothing here fixed it. The shared common issues page works the same ground from the symptom end.