0.9.16
Details
-
FilenamezPermissions-0.9.16.jar
-
Uploaded by
-
UploadedJan 31, 2013
-
Size230.59 KB
-
Downloads1,707
-
MD5512fd50c29e0cb4917142ae712df8c35
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 setzpermissions.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.