Bukkit

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.