Operator is all-or-nothing: it grants every command in the game and every plugin command with it. A permissions plugin exists so you can say «this person can kick, and nothing else», which is what you actually want almost every time.
Giving someone op and then trying to restrict them with a permissions plugin usually does not work — many plugins treat op as an automatic yes. If you are managing permissions properly, your staff should not be operators at all. Op belongs to the console and to you.
A structure that scales
- Build groups, not individuals
default,trusted,mod,admin. Assigning a person to a group takes one command; changing what forty individuals can do takes forty. - Use inheritance
modinherits everythingtrustedhas, plus its own. You then only ever describe the difference, which is where mistakes stop happening. - Grant nodes, not wildcards
essentials.kickis a permission.essentials.*is every command that plugin will ever have, including ones added in a future update you have not read about. - Test by joining as a normal player
An alt account in the
defaultgroup is the only reliable way to see what a new player actually sees. Checking from your own account tells you nothing.
A sensible starting shape
| Group | Gets |
|---|---|
default | Basic commands: spawn, home, tpa, msg. |
trusted | Default plus larger claims, colour in chat, more homes. |
mod | Trusted plus kick, mute, tempban, teleport to players. |
admin | Mod plus ban, region editing, plugin management. |
Most permissions plugins support a comment or a description. In six months, «why can trusted do this?» is a question you will ask about your own configuration, and the answer will not be in your head.
A test account in default can use the basics and gets a clear denial for anything above it.