0.9.15

Details

  • Filename
    zPermissions-0.9.15.jar
  • Uploaded by
  • Uploaded
    Nov 21, 2012
  • Size
    230.23 KB
  • Downloads
    1,927
  • MD5
    1ba37ba48cfcdfb7a1f64e122a599683

Supported Bukkit Versions

  • CB 1.4.5-R0.2

Changelog

0.9.15

  • /permissions import will now immediately halt upon hitting a non-critical error (like attempting to set a permission on a non-existent group).
  • No longer log an exception when attempting to tab-complete a non-existent sub-command. Simply complain to the issuer and move on.
  • Now checks for explicit negation in track-based wildcard permissions. For example, you can now grant someone the zpermissions.promote.* permission and set zpermissions.promote.mytrack to false. They will then be able to promote players on any track except mytrack.
  • Add -v option to rank commands to always echo result to issuer.
  • Add /permissions player <player> dump and /permissions group <group> dump sub-commands to recursively display all permissions set by zPermissions.
  • Add /permissions inspect command to dump the effective permissions of an online player.
  • The player/group "show" commands now use the line pager introduced in this update. (The pager is only active when issuing the commands in-game.)
  • A simple filter option (-f) has been added to the player/group "show" commands, similar to "dump" (i.e. a substring match).
  • Unhide the opaque-inheritance option, adding it to the config file. This is in preparation of possibly switching its default value in some future version.

This version will upgrade your config.yml after backing it up. Be sure to inspect config.yml after it is upgraded, especially the tracks section.

0.9.14

This release requires CraftBukkit 1.3.2-R2.0.

  • Add support for tab-completion, made available to plugins in CraftBukkit 1.3.2-R2.0. Almost everything can be tab-completed... except for permission nodes. :P
  • Sort permissions in output of "show" commands.
  • Add auto-refresh feature governed by the new auto-refresh-interval option. This is a periodic version of the /permissions refresh command, which reloads the contents of the database. (Since the DB has now more or less been permanently cached since 0.9.13.) Might be useful for multi-server setups?
  • Removal of old database storage code along with the /permissions cache sub-commands and the various cache options (cache-max-idle, cache-max-ttl and cache-size)

Your config.yml will be upgraded after being backed up. Double-check your tracks as the track named default may make a return (if you removed it), or the default groups may get added to it.

0.9.13

  • Major change to the database storage code. The entire database is read once at startup. Any changes to permissions (set, unset, promote, etc.) are reflected immediately and are written to the database by an asynchronous task.
  • Added new command /permissions refresh to re-read the database and update all online players' permissions. /permissions reload will also re-read the database as well as config.yml. In both cases, the database queries are issued asynchronously so as to not the lag the server.
  • Refreshing the permission attachment of online players is now rate-limited at 1 player/5 ticks. Originally, it would try to refresh all online players at once, which caused major lag. The limit rate can be configured by the (currently) hidden option bulk-refresh-delay.
  • In addition to the above, when setting or unsetting permissions, only the minimum number of online players are refreshed in order to pick up the new changes. /permissions refresh and /permissions reload will, however, refresh the permissions of all online players regardless.
  • Many other performance enhancements (e.g. setting permissions in Bukkit's PermissionAttachment, reusing attachments, etc.)
  • Lots of code clean up.
  • Many bug fixes to the flat-file-based storage method. It should now be on-par with the new database storage method.

0.9.12

Note: 0.9.12 was broken and pulled from DBO.

0.9.11

  • Add -Q option to rank commands to broadcast changes to all users.
  • Add default track if one was not read from config.yml.
  • More checks for missing groups in rank commands.
  • Resolver scope precedence now applies at a global scale rather than locally at each "level."

0.9.13

As mentioned in the change log, the database storage method changed. The entire database is read at startup and cached until /permissions refresh or /permissions reload. So if you make changes to the database outside of zPermissions, you will have to issue one of these commands at the console.

If this is an inconvenience, let me know via a ticket. I have plans to eventually add configurable auto-refresh (for the new storage method) and/or bring the old non-asynchronous storage method back as an option.

0.9.11

The resolver change, though subtle, has significant implications. Please review any permissions that are subsequently overridden, either due to group inheritance or by being declared directly on the player. Overridden permissions that vary in scope (e.g. the original permission is "universal" and then subsequently overridden by a world-specific permission... or vice-versa) may be affected.

As reminder, the precedence order is:

  • "Universal" permissions (non-world and non-region specific)
  • World-specific permissions
  • Region-specific permissions
  • World- and region-specific permissions

Apologies for the change, but hopefully now that the precedence order is calculated globally, it will be far more intuitive.