Pages

Known Issues

Known Issues

(Also see accepted defect tickets for issues that are currently fixed in a dev version and/or will be fixed in the next release.)

  • Residence 3.0 compatibility Residence 3.0+ has a totally new API that is not backwards compatible. You will see errors whenever players cross residence boundaries. If you run zPermissions with Residence 3.0, it is recommended that you turn off region-support in zPermissions' config.yml. A future version of zPermissions will use the new API (most likely post-1.3).

  • Essentials compatibility Older versions of Essentials (2.11.1 and older) did not recognize zPermissions as a permissions plugin. By default, it will fall back to using the "player-commands" section in its config.yml to determine access to commands. To get Essentials to instead use (SuperPerms) permissions, remove the entire "player-commands" section from its config.yml.

  • EssentialsChat & merging player/group prefixes When I wrote the zPermissions handler for Essentials long ago, I coded it directly against the zPermissions API. Unfortunately, all of the recent chat improvements (such as vault-player-prefix-format) were implemented at zPermissions' Vault layer. This means that any config.yml option that has "vault" in its name cannot be used with EssentialsChat.

  • Towny compability Older versions of Towny do not support zPermissions or Vault. My pull request was accepted, so some future version of Towny may have this support. (I have not checked Towny as of December 2013, so it might already have the new code.) For now, you should be able to use the SuperPerms method for setting prefix/suffix and info/option nodes.

  • XRay Informer The current released version of XRay Informer (3.0.1) includes the Joda Time package in its jar. This causes NoClassDefFoundError exceptions with any Avaje Ebean-using plugin, of which zPermissions is one. There is an open ticket regarding this at XRay Informer.

  • "worldName must have a value" exception Under certain circumstances, Vault-using plugins may throw this exception due to a bug in the zPermissions API/Vault implementation. See this ticket for details. Dev build #422+ fixes the issue. The upcoming release (1.1) will fix it as well.

  • Plugin managers and child permissions Plugin managers (such as PlugMan and PluginManager) cause issues with child permissions (those defined in the plugin's plugin.yml). Child permissions, such as those in plugin.yml, the global Bukkit permissions.yml, or registered programmatically by the plugin, are all handled Bukkit-side. So any issues with child permissions is most likely not a zPermissions issue.