zPermissions — A Superperms plugin for Bukkit
zPermissions is primarily an SQL database-backed Superperms (aka Bukkit permissions) implementation. It also supports flat-file storage. Notable features are: multi-world support, ranks with multiple tracks/ladders, group inheritance of arbitrary depth (within reason), and optional region-specific permissions using WorldGuard regions, Residence residences, Factions territories, or Factoid lands.
There is no built-in build protection (I rely on other plugins for that). zPermissions focuses on permissions and only permissions.
I aim to keep zPermissions a simple, yet feature-rich, Superperms provider.
zPermissions supports UUIDs as of the 1.3beta1 release! See the notes for that release for details.
If your question is still unanswered, please post on the forum.
Finally, for any bugs/issues, please create a dev.bukkit.org ticket.
Unless I already know you, PMs will be ignored.
A variety of storage options, from SQL to flat-file. Uses Bukkit database to store permissions (i.e. settings in bukkit.yml). Should work with most databases supported by Avaje Ebean — I've specifically tested with PostgreSQL, MySQL, and H2. The default Bukkit database, SQLite, is not supported. zPermissions will automatically fall back to flat-file storage if it is used.
Group inheritance. Groups may inherit permissions from a multiple parent groups.
Players may be members of more than one group. The order of which group permissions are applied is well defined and based on group weight (which is configurable, of course).
Multi-world support. Permissions granted to players and groups may be associated with a specific world.
Optional region support. Permissions may also be associated with WorldGuard regions or Residence residences.
Multiple promotion tracks! Using permissions, you can also limit who can promote/demote others and which tracks they may use. In addition, each player may be promoted/demoted along multiple tracks.
Short-term temporary permissions. Give a player a permission node that lasts anywhere from a few seconds to a few minutes.
Temporary group assignments. Assign a group to a player and have their membership expire after 1 day... a few months... or a year! Whatever duration you want.
API. zPermissions offers a comprehensive read-only API that other plugins can use. (Though I would recommend coding against Vault instead.)
Metadata support. Players and groups may have arbitrary metadata associated with them. Metadata values may be strings, integers, reals (floating point), and booleans. Metadata may be queried via the native API or Vault Chat API.
Automatic group permissions. With the advent of Superperms/Bukkit permissions, the recommended way of testing group membership is by using permissions. zPermissions can automatically set a permission based on the group's name for each group. By default, this configurable permission is
group.<groupname>(compatible out-of-the-box with WorldEdit and WorldGuard!).
Re-assignable default group. The default group (the group assigned to players who have not been explicitly placed into any groups) is named
default. This may be changed.
Groups are "universal" — across all worlds. There are no plans to introduce world-specific groups.
However, players and groups may have world-specific and/or region-specific permissions. These permissions are only in effect when the player is in that particular world and/or region.
There are 4 "levels" of permissions: universal, world-specific, region-specific, and finally region- and world-specific. The most general permissions are applied first, with all group permissions applied first finally followed by player permissions:
- Universal group permissions
- World-specific group permissions
- Region-specific group permissions
- Region- and world-specific group permissions
- Universal player permissions
- World-specific player permissions
- Region-specific player permissions
- Region- and world-specific player permissions
Players may be members of multiple groups. Groups may be assigned a weight — a higher weight means the group is applied later so it overrides earlier groups. Groups with the same weight are applied alphabetically.
Groups may inherit from one or more parent groups. A group's parents are applied in reverse order so that a group's first parent overrides all subsequent parents.
Installation & Usage
Put zPermissions.jar in your server's
plugins directory. Start up your server. This will create the file
config.yml in your server's
plugins/zPermissions directory. You may want to edit this file to set your default group and default track. You may also want to create your tracks.
/permissions to get started. (
/p may also work, if those aliases are available.)
The permission nodes in the
unset sub-commands may be specified as:
- <permission> — An unqualified permission node applies to all worlds and all regions.
- <world>:<permission> — To make a permission world-specific, prefix it with the world name followed by a colon.
- <region>/<permission> — To make a permission region-specific, prefix it with the region name followed by a slash.
- <region>/<world>:<permission> — You may also make a permission both region- and world-specific by combining the two qualifiers. For now, the region qualifier must always come first.
The rank commands are
/unsetrank and will normally broadcast changes to all admins. The rank commands have an option
-q to operate silently, e.g. when being called by automated processes. They will, however, still log their actions to the server log for security audit purposes. Opposite of
-q, they will also take
-Q which causes the rank commands to broadcast changes to all users.
- Detailed Command Usage
- Temporary Permissions & Groups
- Customizing Table Names
- Vault Support
- For Plugin Developers
- Schema Updates
License & Source
zPermissions is released under the Apache License, Version 2.0.
Sources may be found on GitHub:
Development builds of this project can be acquired at the provided continuous integration server.
These builds have not been approved by the BukkitDev staff. Use them at your own risk.
- zPermissions (Requires ToHPluginUtils.jar)
- zPermissions-standlone (includes ToHPluginUtils, like the version distributed on dev.bukkit.org)
- More extensive unit tests, especially on the service interface.
- Better organized docs.
Note: The next version will have UUID support. See this ticket for the current plan as well as a tentative migration procedure.
This version adds new config.yml options:
This version adds new permissions:
- zpermissions.cleanup (also added to zpermissions.*)
- zpermissions.search (also added to zpermissions.*)
- zpermissions.notify.expiration (also added to zpermissions.notify.*)
- Add metadata inheritance.
- Add option to log changes made through Vault. (On by default)
- Allow player & group prefix/suffix to be merged in a configurable way.
- Add /permissions cleanup command which for now only deletes expired group memberships.
- Add /permissions search command.
- Add missing refresh feature to flat-file storage.
- Rework initialization so storage errors and only storage errors are retried indefinitely.
- The /perm mygroups command will no longer list expired memberships by default. Use -v to get the old behavior.
- Add notification for expiring temporary group memberships (of online players only).
- Add permission to send membership expiration notices to 'self.'
- Move debug logging from FINE to CONFIG to match new mapping. [zPerms & ToHPluginUtils]
- Abort batch processing when encountering permission, parse, or general exceptions. [ToHPluginUtils]
- Abort batch processing when encountering read-only errors or displaying help.
- Remove the duration/timestamp parameter from player..removegroup (added by mistake, doesn't actually do anything)
- Fix issue with Vault groupRemove() implementation.
I added this feature for completeness. I still do not recommend that you edit data.yml directly. However, if you must, you can have zPermissions re-read the file by issuing /perm refresh or /perm reload. Note that any pending writes will be discarded (by default, zPermissions will wait up to 10 seconds after making a permissions change before writing out the flat-file). Use at your own risk!Changes to Initialization Error Handling
Prior to this release, zPermissions would block all logins/all non-op logins (depending on configuration) if any error occurred during initialization. This release changes the behavior somewhat: initialization of permissions storage (e.g. database) will be retried indefinitely. If the initial attempt fails, it will wait 30 seconds. If the 2nd attempt fails, it will retry after 60 seconds. Third attempt, 120 seconds, etc., doubling the interval after each attempt (up to a maximum of 480 seconds or 8 minutes).
While it is attempting to initialize storage, no logins will be allowed at all and no other plugins will be allowed to initialize. Basically, zPermissions will stall the server startup until it can successfully read its permissions.
Note that errors anywhere else in initialization (which should be rare) will cause zPermissions to block logins as before.
|File Name||Release Type||Game Version||Downloads||Date|
- Developer Tools and Admin Tools
- 298,707 Monthly Downloads
- Ores and Resources, Player Transport, Technology, and Processing
- 236,423 Monthly Downloads
- Soartex Fanver
- Mod Support, Animated, Traditional, Modern, and 64x
- 218,575 Monthly Downloads
- World Editing and Management and Admin Tools
- 213,238 Monthly Downloads
- Tinkers Construct
- Mobs, Processing, Technology, and Armor, Tools, and Weapons
- 173,555 Monthly Downloads