0.9.16

Details

  • Filename
    zPermissions-0.9.16.jar
  • Uploaded by
  • Uploaded
    Jan 31, 2013
  • Size
    230.59 KB
  • Downloads
    1,646
  • MD5
    512fd50c29e0cb4917142ae712df8c35

Supported Bukkit Versions

  • CB 1.4.7-R1.0

Changelog

0.9.16

  • Catch respawn events so respawning in a different region is immediately noticed.
  • Deal with deprecation of scheduleAsync methods.
  • Fix minor bug with flat-file storage that prevented periodic saving after the first auto-save.
  • Correctly consider player in the default group when performing a rank command.
  • Fix getPlayerGroups() method in ZPermissionsService interface so it correctly returns default group. (Affects Vault and Vault-enabled plugins.)

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.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.