Permissions

The design in one paragraph

There are two kinds of node here, and the difference is not their name — it is whether plugin.yml declares them.

The nodes a player needs to use the plugin at all are declared, each with a default, so a fresh install works before you have configured a permission plugin: everybody can open the menu, whisper and show what they hold, and only operators can run the admin command. Every node that says a player owns a cosmetic is deliberately not declared. An undeclared node in Bukkit defaults to operators only, so nothing in the catalogue is anybody's until you say so — which is exactly what makes a cosmetic something you grant rather than something everyone already has.

Using the plugin

The four .create nodes are permission to make one at all. How many a player may then make is a token balance, not a node — see Tokens.

Owning a cosmetic

Four shapes, checked in this order. Any one of them owns it.

The types are tag, nick_color, rank_color, chat_color, shadow_color, font and modifier — the seven that come from files. The four a player writes for themselves — customtag, customcolor, customnick, customrank — have no ownership nodes at all: whoever made one owns it, permanently, the way a node would.

The permission is asked live, every time, and never stored. That is why revoking a node takes effect the moment it is revoked, even for a player who is offline while you do it.

The two exceptions

An entry may write permission: false, and then the ownership nodes above are not consulted for it at all. It is held only through a grant — /cca give, a purchase, an API call. Use it for anything that must be bought or won rather than assigned to a group.

Rank colours start from the opposite default. Everywhere else an entry that says nothing about permission is read as permission: true. In rank-colors.yml an entry that does not mention permission is read as false instead, and ownership falls to the entry's groups list:

That is the mechanism, not a description of the type: all three cases are in the shipped file. Of its 77 entries the 15 in SOLID name neither, so every rank may wear them; the 12 in METAL, 15 in GEMS, 15 in GRADIENT and 12 in ANIMATED each write permission: true, so they need a node or a grant like anything else; and only the 8 in STAFF are owned by groups. A player in admin wears the admin colour because they are in admin, and stops wearing it the day they are not — which is why that tab needs no node at all, and why the group names in it are guesses at yours and want editing. Group membership comes from LuckPerms, so rank colours need it.

The chat module

Every node below applies only while the module is running. Nothing here is checked with it off.

Commands

A command whose switch in chat/config.yml → commands is off is not registered at all, and its node then grants nothing.

What a player may write

Staff

Bypasses

Undeclared, so operators only until you say otherwise. Each one skips exactly one check.

Content

Three more nodes exist, and their names are yours rather than the plugin's, because each comes from a file:

Note that exyliachatcosmetics.chat.format and a format node like exyliachatcosmetics.chat.format.vip are unrelated nodes — Bukkit gives no node authority over the ones below it. Granting the second does not grant the first.

The declared defaults, in full

Everything below is what plugin.yml writes. Everything not on these two lists is undeclared, and therefore operators only.

default: true — everybody, including a server with no permission plugin: command.cosmetics, customtag.create, customcolor.create, customnick.create, customrank.create, chat.command.msg, chat.command.reply, chat.command.ignore, chat.command.ignoreall, chat.command.channel, chat.mentions, chat.render.item, chat.render.inv, chat.render.ec.

default: op — operators until you grant them: admin, chat.command.spymsg, chat.command.mutechat, chat.command.clearchat, chat.command.broadcast, chat.links, chat.format, chat.staff, chat.staff.alerts, chat.staff.filtered.