Roles & Permissions
Each town owns a list of TownRoles, and each role carries an EnumSet<PermissionType>. Permission checks for both passive listeners (block break, container open, etc.) and active commands (/town claim, /town invite, …) walk the player's role.
Role model
Field | Type | Description |
|---|---|---|
| UUID | Primary key. |
| UUID | Owner town. |
| UUID? | When set, the role is subzone-scoped to that subzone. Town-wide roles leave this null. |
| String | Internal identifier. |
| Component | MiniMessage shown in menus. |
| String | Free text. |
| boolean | The role granted to every new member. Exactly one per town (or per subzone). |
|
| What this role can do. |
| int | Default role: |
Seed roles
roles.yml > default-roles defines the roles created automatically with every new town. Exactly one entry must set is-default: true — that role becomes the default for new members. See Configuration.
CRUD
Roles are managed through dialogs powered by the create-town-role, edit-town-role, and delete-town-role actions (see Actions). Common entry points are inside the town menu hub.
Cannot:
Delete the default role (
CANNOT_DELETE_DEFAULT_ROLE).Modify a role owned by a player at a higher weight than yours (
CANNOT_MODIFY_HIGHER_ROLE).Modify your own role (
CANNOT_MODIFY_SELF_ROLE).Modify the owner's role (
CANNOT_MODIFY_OWNER_ROLE).
Each mutation writes an audit log entry — see Logs.
Assigning roles
Path | Permission |
|---|---|
|
|
Menu via |
|
The cycle-member-town-role action moves the member to the next role by weight, looping at the top.
Permission catalogue (PermissionType)
83 typed permissions, grouped by area:
World & interaction
Permission | Gate |
|---|---|
| Whether non-members may step inside claims. |
| Place blocks. |
| Break blocks. |
| Break monster spawners specifically. |
| Light blocks on fire (flint, lava). |
| Plant saplings, crops. |
| Break grown crops. |
| Right-click harvest (berries, sweet berries). |
| Step on farmland and trample it. |
| Shear sheep and certain blocks. |
| Item handling. |
| Any non-specialised interaction. |
| Self-explanatory. |
| Pistons, dispensers, redstone wired devices. |
| Chests, barrels, hoppers, shulkers. |
| Per-block UIs. |
| Place / rotate / remove. |
| Sign editing. |
| Boats, minecarts. |
| Combat. |
| Flight modes. |
| Use pearls inside claims. |
| Ranged. |
| Misc movement. |
Members
Permission | Gate |
|---|---|
|
|
|
|
|
|
Roles
Permission | Gate |
|---|---|
| Create / edit / delete roles. |
| Assign a role to a member. |
| Toggle the permission entries inside a role. |
Town governance
Permission | Gate |
|---|---|
|
|
| Spawn management. |
|
|
| Toggle |
|
|
| Reserved; ownership transfer is currently owner-only. |
Economy
Permission | Gate |
|---|---|
| Town bank ops. |
Features
Permission | Gate |
|---|---|
| Create / delete warps. |
| Read the audit log. |
| Subzone CRUD. |
| Use the pet system inside the claim. |
| Spawn shop signs inside the claim. |
| Use |
| CraftEngine furniture. |
| Reserved for the inter-town diplomacy API. |
| Use |
| Use |
Permission resolution
Town.hasPermission(player, type, location) and the matching subzone overload follow this order:
If the player has
town.admin, returntrue.If they are the owner, return
true.If the location is inside a subzone:
If the player is a subzone member, use their subzone role's permissions.
Otherwise fall through to step 4.
Use the player's town role's permissions.
TownAPI.hasPermission(player, location, type) resolves the same way and is the recommended entry point for external plugins.