Overview

How the permission system fits together, and where to look for each part.

Three rules apply everywhere in this section. Knowing them saves reading every page.

An unlisted node is OP-only

BuildSystem declares its fixed nodes in plugin.yml, and Bukkit falls back to OP-only for any node that is not declared there -- which includes every dynamic node, since ids like a category or status name are only known at runtime. So a node you do not see in a table below is almost certainly OP-only, not open to everyone. Each page states the default explicitly.

.self and .other scope a command to whose world it is

Most world commands accept two suffixes. buildsystem.delete.self allows deleting worlds you created; buildsystem.delete.other allows deleting anyone's. The bare buildsystem.delete covers your own. This is why granting a bare node rarely lets staff work on other people's builds -- see Command Permissions for the full rules.

buildsystem.admin is the master key

It bypasses per-world locks, builder lists, category restrictions, and world limits in one node. Grant it only to people you would trust with the console.

Navigation

• Command Permissions: Full command list permissions and the .self/.other logic.

• Navigator Item Permissions: Permissions for using and receiving the Navigator item.

• World Access Rules: Restricting entries, and configuring builder lists.

• World Creation Rules: Limiting public/private worlds, and templates/generators.

• Bypass & Admin Nodes: Administrative bypasses for archived or locked worlds.

• Color Codes & Alerts: Color formatting permissions and physics alerts.