1.2

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:

• inherited-metadata
• log-vault-changes
• vault-player-prefix-format
• vault-player-suffix-format

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.*)
• zpermissions.notify.self.*
  • zpermissions.notify.self.expiration

Changes

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

Notes

Flat-File Refresh

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.

Depending on how active your Vault plugins are, your server log may end up getting spammed with messages.

You can disable these messages by setting log-vault-changes to false in config.yml (located near the bottom).

Depending on feedback, I may make false the default in the future.