0.9.17
Details
-
FilenamezPermissions-0.9.17.jar
-
Uploaded by
-
UploadedMar 20, 2013
-
Size231.41 KB
-
Downloads914
-
MD56a594b0e4827371eafedcfa69d311737
Supported Bukkit Versions
- 1.5.1
- CB 1.4.7-R1.0
Changelog
0.9.17
- Fix getPlayerAssignedGroups() in ZPermissionsService so it also correctly returns the default group. (Affects Vault and Vault-enabled plugins.)
- Add 'has' command which simply outputs the result of Bukkit's hasPermission() method.
- Don't make the -v option to inspect a toggle. That's just confusing. When executing inspect from the console, it will always be verbose; -v will do nothing.
- Clean up of attachment and player state handling.
- Store player state as Bukkit metadata to avoid potential desynchronization of state between Bukkit and zPermissions.
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.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.