Permissions

The plugin supports various permissions to allow admins to control who can do what.

A Note About Bukkit SuperPerms

Transporter doesn't and can't support SuperPerms because Bukkit's permission system doesn't allow permissions to be checked for offline players and non-players (e.g., gates). This is a requirement of the plugin because it needs to be able to check permissions on a destination server __before__ a player logs into that server. I've made a suggestion to the Bukkit team about how to rectify this, but I have yet to receive a response.

Op

The Minecraft server has the notion of an "op" or admin user. The Transporter plugin always honors "op" mode and a player with "op" has permission to do anything with the plugin regardless of the any other permissions. The plugin determines if a player has "op" by directly reading the server's ops.txt file.

Basic Permissions

NOTE: v7.7 introduced some new syntax and behavior for the basic permissions system. The documentation below applies to v7.7 and above.

The basic permissions system is built into the plugin and is enabled by default after initial installation. If any other permission system is enabled in the global configuration, the basic permissions system is disabled automatically.

All the basic permissions are controlled by the permissions.properties file located in the plugin folder. Depending on the age of your initial plugin installation, the file may have instructions embedded in it. Newer versions of the plugin don't include the instructions since they're documented here.

The file uses a simple name/value based syntax. The characters to the left of an equal sign form a dot-separated permission node and the corresponding value is a comma-separated list of player names.

Permission nodes are hierarchical where each dot ('.') denotes a level of the hierarchy. Permissions are checked in a most-specific to least-specific order. If a permission is granted in a more-specific node, the lesser-specific nodes are ignored.

An asterisk (*) may be used as the last component of a permission node to match all permission nodes 'below' that node in the hierarchy.

The player names on the right of the equal sign grant the named players the corresponding permission. If a player name has no prefix, or a '+' prefix, the player is granted the corresponding permission and no further checks are performed. If the player name has a '-' prefix, the player does not have the corresponding permission and no further checks are performed. If an asterisk ('*') is used, it matches all players and no further checks for performed. If the asterisk is prefixed with '-', all players are denied the corresponding permission and no further checks will be performed.

The default basic permissions are:

trp.*=*

This grants all players all Transporter permissions. This is very lenient and should be changed for serious setups.

A better set of permissions might be:

trp.gate.use.*=*
trp.gate.open.*=*
trp.gate.close.*=*

And then make sure some trusted users are "ops". This allows non-op users to open/close and travel through gates, but only ops can manage everything.

See Permission Nodes below for details about available permission nodes.

The permissions.properties file is never overwritten during a plugin upgrade, so your changes are safe.

Examples

To give the players 'Player1', and 'Player2' the ability to get information about any gate, but 'Player3' can only get permissions about any gate in the world named 'world':

trp.gate.info.*=Player1, Player2
trp.gate.info.world.*=Player3

To give all players all permissions:

trp.*=*

Permissions Plugin

To enable the Transporter plugin to make use of the Permissions plugin, set the usePermissions global configuration to true:

trp set usePermissions true

See Commands and Permission Nodes below for details about available permission nodes.

PermissionsEx Plugin

To enable the Transporter plugin to make use of the PermissionsEx plugin, set the usePermissionsEx global configuration to true:

trp set usePermissionsEx true

See Commands and Permission Nodes below for details about available permission nodes.

Permission Nodes

Every console/client command the plugin supports has an associated permission node. See the Permission column on the Commands page for the applicable permission node for any command.

In addition to the nodes used to control access to the plugin's commands, the following nodes are available:

Permission	Description
trp.create.<design>	Determines if a player is allowed to create a gate based on the named design.
trp.gate.use.<gate>	Determines if a player can use the named gate for travel. A player must have this permission for _both_ the sending and receiving gates. The gate name is the gate's full name (i.e., with world name).
trp.gate.open.<gate>	Determines if a player has permission to open a gate by interacting with (punching) the gate's trigger. This is the same permission used for the trp gate open ... command.
trp.gate.close.<gate>	Determines if a player has permission to close a gate by interacting with (punching) the gate's trigger. This is the same permission used for the trp gate close ... command.
trp.gate.changeLink.<gate>	Determines if a player has permission to change a gate's current destination by interacting with (punching) the gate's switch.

Gate Permissions

Gates can have permissions, much like players. Gate permissions allow an administrator to restrict which gates can send and receive entities between other gates. In order to use gate permissions, you must enable the global configuration option:

trp set useGatePermissions true

You can then configure permissions using a gate's simple name as if it were a player's name.