[ADMN/DEV] PermissionsBukkit v2.0 - Official Default Groups Plugin [1.5.2-R1.0]

Discussion in 'Archived: Plugin Releases' started by SpaceManiac, Jul 17, 2011.

  1. Offline


    PermissionsBukkit - the Official Default Groups Plugin
    Current Version: v2.0
    Find PermissionsBukkit on BukkitDev!

    If you are getting a specific error or cannot determine what is wrong with your permissions file, filing a ticket on BukkitDev will make me much more likely to respond to you; general questions are best to ask in this thread or on the forums on BukkitDev.

    It's been a long time coming, but with the accomplishment of build 1000 Bukkit has finally accomplished a built-in Permissions system (codenamed Superperms). For more info on how they work, and how to integrate them with your plugin, see the official Permissions FAQ. Keep in mind that you should rarely, if ever, have to hook this plugin directly; instead keep things in the realm of checking player.hasPermission("yourplugin.node"). The FAQ thread has more info on how to use Superperms with things like chat prefixes/suffixes.

    • Storage of users and groups in plugins/PermissionsBukkit/config.yml.
    • Both users and groups can be assigned individual permissions and parent groups to inherit permissions from.
    • Support for global and per-world permissions.
    • Reload configuration from file with out reloading the plugin.
    • Ability to check if a player has a specific permission node.
    • Ability to dump all permissions a player has and the plugins that set them.
    • Ability to print plugin, description, and default for a given permission node.
    • Ability to modify the permissions of groups and users and the groups of a user in-game.
    • Built-in antibuild via the "permissions.build" node (defaults to allowing anyone to build).
    • A minimalistic bridge from Permissions 3.0 to Superperms is available as a separate plugin, which does not depend on PermissionsBukkit.
    Command Usage:

    Show Spoiler
    PermissionsBukkit uses the command /permissions, with aliases /perms and /perm.

    /permissions reload - reload the configuration from disk.
    /permissions check <node> [player] - check if a player or the sender has a permission (any plugin).
    /permissions info <node> - prints information on a specific permission.
    /permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
    /permissions setrank <player> <group> - set a player to be in a group with per-group permissions.
    /permissions group - list group-related commands.
    /permissions group list - list all groups.
    /permissions group players <group> - list players in a group.
    /permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group.
    /permissions group unsetperm <group> <[world:]node> - unset a permission on a group.
    /permissions player - list player-related commands.
    /permissions player groups <player> - list groups a player is in.
    /permissions player setgroup <player> <group,...> - set a player to be in only the given groups.
    /permissions player addgroup <player> <group> - add a player to a group.
    /permissions player removegroup <player> <group> - remove a player from a group.
    /permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player.
    /permissions player unsetperm <player> <[world:]node> - unset a permission on a player.

    All commands have in-game help and are usable from the server console.

    Show Spoiler
    A permission node is a string like 'permissions.build', usually starting with the name of the plugin. Refer to a plugin's documentation for what permissions it cares about. Each node should be followed by true to grant that permission or false to revoke it, as in 'permissions.build: true'. Some plugins provide permission nodes that map to a group of permissions - for example, PermissionsBukkit has 'permissions.*', which automatically grants permissions for all PermissionsBukkit commands. You can also specify false for permissions of this type.

    Users inherit permissions from the groups they are a part of. If a user is not specified here, or does not have a 'groups' node, they will be in the group 'default'. Permissions for individual users may also be specified by using a 'permissions' node with a list of permission nodes, which will override their group permissions. World permissions may be assigned to users with a 'worlds:' entry.

    Groups can be assigned to players and all their permissions will also be assigned to those players. Groups can also inherit permissions from other groups. Like user permissions, groups may override the permissions of their parent group(s). Unlike users, groups do NOT automatically inherit from default. World permissions may be assigned to groups with a 'worlds:' entry.

    The cannot-build message is configurable. If it is left blank, no message will be displayed to the player if PermissionsBukkit prevents them from building, digging, or interacting with a block. Use '&' characters to signify color codes.

    An example configuration file might look like this:
                permissions.example: true
            - admin
                permissions.build: false
                permissions.*: true
            - user
                permissions.build: true
                    coolplugin.item: true
            - default
        build: '&cYou do not have permission to build here.'

    Show Spoiler
    PermissionsBukkit checks for the following permission nodes:
    • permissions.build - Allows a player to build. Defaults to true.
    • permissions.help - Allows viewing of usage for /permissions.
    • permissions.reload - Allows use of /permissions reload.
    • permissions.check - Allows use of /permissions reload.
    • permissions.info - Allows use of /permissions reload.
    • permissions.dump - Allows use of /permissions reload.
    • permissions.group.help - Allows viewing of usage for /permissions group.
    • permissions.group.list - Allows use of /permissions group list.
    • permissions.group.players - Allows use of /permissions group players.
    • permissions.group.setperm - Allows use of /permissions group setperm.
    • permissions.group.unsetperm - Allows use of /permissions group unsetperm.
    • permissions.player.help - Allows viewing of usage for /permissions player
    • permissions.player.groups - Allows use of /permissions player groups.
    • permissions.player.setgroup - Allows use of /permissions player setgroup.
    • permissions.player.addgroup - Allows use of /permissions player addgroup.
    • permissions.player.removegroup - Allows use of /permissions player removegroup.
    • permissions.player.setperm - Allows use of /permissions player addgroup.
    • permissions.player.unsetperm - Allows use of /permissions player removegroup.
    Also, the following parent nodes are provided for convenience:

    • permissions.* - Maps to permissions.help, .reload, .check, .info, .dump, and to permissions.group.* and permissions.player.*. Defaults to op.
    • permissions.group.* - Maps to permissions.group.help, .list, .players, .setperm, and .unsetperm.
    • permissions.player.* - Maps to permissions.player.help, .groups, .setgroup, .addgroup, .removegroup, .setperm, and .unsetperm.

    Frequently Asked Questions:
    1. Where are my * nodes? (open)
    Bukkit's Superperms has no built-in concept of a global '*' node that automatically gives all permissions, which is intentional - a player can instead be given all permissions by being given 'op' status (that is, listed in ops.txt). Additionally, individual plugins define a parent node (which could be 'pluginname.*' or 'pluginname.all' or anything else) which maps to whatever subpermissions in that plugin the author desires.

    An example is PermissionsBukkit, which provides three such permissions: 'permissions.group.*' for all /permissions group commands, 'permissions.player.*' for all /permissions player commands, and'permissions.*' for all /permissions commands (including permissions.group.* and permissions.player.*).

    If you are using SuperpermsBridge, you can do something similar to '*' nodes for plugins which use Permissions 2.7/3.1 - see the next FAQ for more information.
    2. How do I use SuperpermsBridge? (open)
    SuperpermsBridge is kind of like FakePermissions for GroupManager or PermissionsBridge for PermissionsEx. Once it's installed, it pretends to be the Permissions plugin and converts any plugins that use Permissions 2.7 or Permissions 3.1 to use Superperms instead.

    You can have PermissionsBukkit without SuperpermsBridge or SuperpermsBridge without PermissionsBukkit if you like, but both of these are limited in functionality. If you install SuperpermsBridge without PermissionsBukkit you will not be able to make use of PermissionsBukkit's groups feature or admin commands, and if you install PermissionsBukkit without SuperpermsBridge, plugins that have not updated to use Superperms directly will not function.

    For plugins that use Permissions 2.7/3.1, you can use the special node 'superpermbridge.*' to give the equivalent of what used to be the '*' node for plugins that do not use Superperms directly. If you don't want to give the * node, you can also use the node 'superpermbridge.pluginname' to do the equivalent of what used to be the 'pluginname.*' node. Once again, these only apply to plugins that SuperpermsBridge handles and not to plugins using Superperms directly.
    3. How do I use the root permissions.yml? (open)
    The file 'permissions.yml' in the root of your server can be used to set up custom parent permissions. Parent permissions are a single node that, when given to a player or group, automatically give all their children node. Here's a simple example:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    Now, if you give a player the node 'server.basics', they automatically get all the nodes listed here. Children may also say 'false' instead of 'true', in which case giving the parent will remove the child instead of giving it.

    You can also specify a description if you like, which can be used by plugins to provide information on your node (such as PermissionsBukkit's /perm info command). If you want, you can also provide a default, which can be one of "true", "false", "op", or "notop". CraftBukkit will automatically assign everyone, no one (default), ops, or non-ops the children permissions based on the specified default. Without any plugin like PermissionsBukkit, you can use this defaults system as a limited way to assign people permissions. Here's a more complex example:
        description: Basic permissions for My Cool Server.
        default: true
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
        description: Admin permissions for My Cool Server.
        default: op
            commandbook.broadcast: true
            commandbook.teleport: true
            commandbook.kick: true
            commandbook.ban: true
    You can also define permissions without children, but this is of limited usefulness in permissions.yml (though is important in plugin.yml; see question #6)
    4. How do I switch from (other Permissions plugin)? (open)
    Depends on the Permissions plugin! If you were using PEX's YAML backend, I have a converter done and available on the PermissionsBukkit Tools page. Also available on the tools page is an automatic converter for Essentials GroupManager users.yml and groups.yml files. Automatic converters for Permissions 2.7 and 3.x are on their way, but in the meantime you can still convert your configurations manually.
    5. Where are prefixes and suffixes (or option nodes)? (open)
    Bukkit Superperms has no built-in prefix/suffix settings or non-boolean permission nodes, so individual chat plugins will have to start supporting Superperms in order to make use of non-Permissions-plugin based prefixes and suffixes. Herochat, iChat, and Simple Suffix are all aware of the Superperms update, but in the meantime you can use mChat, which already supports Superperms.

    Once you install mChat and configure the mchat.prefix, mchat.suffix, and mchat.group names in its configuration file (see the example), use PermissionsBukkit to give players or groups the permissions "mchat.prefix.admin", replacing "admin" with whatever node you configured. For example, with an mchat configuration that looks similar to this:
    da-name-format: '+prefix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+name&f: +message'
            admin: '&4DtK [SO] &7 '
            sadmin: '&9DtK [SA] &7 '
            jadmin: '&aDtK [JA] &7  '
            member: '&cDtK [M] &7 '
    You can assign players or groups the mchat.prefix.admin node to get the "SO" prefix, mchat.prefix.sadmin to get the "SA" prefix, and so on.
    6. (Coders) How do I set up my plugin.yml? (open)
    Take a look at this post in Dinnerbone's FAQ for an example. This is a lot like the setup of permissions.yml (see above), but you can also define non-parent permissions (just include description and default and leave out children).
    7. Is PermissionsBukkit outdated? (open)
    No! PermissionsBukkit 2.0 was last updated for 1.3.1-R2.0, is verified to work on 1.4.7-R1.0, and is unlikely to break on future releases.

    Current Version:

    PermissionsBukkit v2.0 (jar) (details)
    Old Versions:
    PermissionsBukkit v1.6 (jar) (details)



    Friday 7 September 2012 (2.0)
    • Fixed a case-sensitivity issue with setting per-world permissions that could cause some permissions to fail to apply.
    • Added /perm setrank <player> <group> subcommand (alias rank) with per-group permissions (permissions.setrank and permissions.setrank.<group>)
    • Added plugin metrics via http://mcstats.org/plugin/PermissionsBukkitMCStats (disableable in plugins/PluginMetrics/config.yml)
    Wednesday 29 February 2012 (1.6)
    • Fixed some massive issues that were caused due to having uploaded a buggy, in-development version instead of 1.5.
    • Note: If your configuration was messed up as a result of this issue, the new build should gradually correct it as needed.
    Saturday 25 February 2012 (1.5b)
    • Revamped to be compatible with R5.
    • Fixed issues with permissions not carrying properly on world change.
    • Many internal improvements for performance and stability.
    • SuperpermsBridge: in honor of R5 removing deprecated code, SuperpermsBridge is officially gone!
    Monday 18 July 2011 (1.1/1.2)
    • Fix BukkitContrib incompatibility issues.
    • Improved the output of the /perm check command.
    • Fixed issues when 'users:' is not specified in the config file.
    • Fixed the /permissions reload command.
    • SuperpermsBridge: improve wildcard handling; in addition to 'superpermbridge.*' and 'superpermbridge.pluginname', now supported are 'superpermbridge.plugin.*', 'superpermbridge.plugin.subnode.*', and so on.
    Monday 18 July 2011 (1.0/1.1)
    • SuperpermsBridge: adding the special 'superpermbridge.*' and 'superpermbridge.pluginname' nodes (see #2 in the FAQ for details).
    Sunday 17 July 2011 (1.0/1.0)

    • Initial release of PermissionsBukkit v1.0 and SuperpermsBridge v1.0.
    madmac, Gesundheit, tripleX and 23 others like this.
  2. Offline


    @SpaceManiac @krinsdeath [​IMG]
    Top is your dev release, bottom is "1.2" neither of them keep permissions for connected players over reload. This is extremely annoying when both developing (I have to d/c every time I update any code) and especially while helping people figure out why a specific plugin isn't working (Regular users /reload their server a lot, they don't think that their perms will be wiped when they do so).
  3. Offline


    I ment since bukkits encore data when Hmod died there should have been a permissions system in place from that day, long before any other plugins started creating systems. Hmod had its built-in permissions since day 1 so go figure :p

    The issue I have with this new system now is not that I can't eventually wrap my head around it, it's more that the system in place before bukkits no longer needed system works perfectly fine and 90% of plugin's up until now worked with it. Bukkit should have put a lot more thought in the system they released as said in prev post its more of a hassle now than a servers asset.

    Maybe there is something I don't understand yet about the new system that makes it THAT much better and draws people in to eagerly wanting to use it but from I have read and the devs/admins I have spoken to think it's just a pain in the rear end now more than anything else and that the 3x permissions should have just been made the norm and given more love. I did some reading on bukkits system but I found it lacked a bit that 3x had native support for.

    I'm in no rush at least not until they finally get pick up their game and release converters to make the transition painless but until then as far as myself and other like-minded are concerned this new system is in its infancy stage and technically it kinda of is considering how long the existing system has been run thru its paces for.

    Not to mention it has little to no detailed instructions for setup or conversion from existing systems I keep reading posts of ppl having issues more so than I have in the past 2 months from the apparently now outdated system users and these are postings from educated dev people who would likely know how to work something out eventually.

    This to me is more of an alarm bell telling me to steer clear of this system for a while.
  4. Offline


    @Drakia - This problem only exists with Spout on the server. Spout does some funky things with attachments and the Player interface, which interferes with PermissionsBukkit. I tried every stable build from 134 - 168 and this problem persisted with all of them. To fix it, I set Spout as a soft dependency in PermissionsBukkit's plugin.yml, but this makes PB load rather late in the startup.

    I know the cause of the problem, and I know how to fix it, but it's a pretty massive rewrite.
    GmK likes this.
  5. Offline


    Thanks for the hint to set Spout as dependency in the plugin.yml!
  6. Offline


  7. Offline


    Hi all,

    Am I missing something?

    It runs without error but,
    I was unable yet to successfully assign permissions to any user.

    The main result is this error message:
    I get this only when I login a user I entered in config.yml
    If login a user not in the config file, it has the right to build but the default is permissions.build: false

    I don't have much installed. I am almost from scratch.
    I am running my server on linux Ubuntu server 11.04 with Sun Java 6.
    I am using PermissionsBukkit-1.1.jar but I have the same problem with bukkit-permissions-0.1.0-SNAPSHOT.jar
    Users I am testing are in white-list.txt

    plugins\PermissionsBukkit\config.yml: (I replaced spaces by ^)
    Plugins list:
    * I removed the log since it's been fixed and the log was irrelevant.

    Than you
  8. Offline


    @TiriPon - First off, thank you for the well written bug report.

    Enclose your user '417' in single quotation marks. The YAML parser is encountering an int(number) when it is expecting a String, so it's exploding. That should fix it.
  9. Offline


    That was it? I feel so stupid - wink.
    Thank you very much for the prompt reply.
  10. Offline


    Anyone that knows?
  11. Offline


    @KrisEike - I do not think this is an issue with PermissionsBukkit. I can't replicate the mysterious "console doesn't have permission to do anything" error except by setting every permission to false in permissions.yml. I have no answer for you at this time.

    I believe removing the SuperpermsBridge might help, as well as confirming that Spout is either 1) not installed or 2) completely bleeding edge.

  12. Offline


    I have Spout installed, yes. Should i remove it?
  13. Offline


    I'm having this issue as well...
  14. Offline


    my moderator just promoted himself to admin......
    Is there a way to give moderators only the permission to set people in certain groups?
    So mods can only change people to be a guest/builder/elite builder.
    And make it impossible to lower or raise a moderators in rank?
  15. Offline


    @Snowy007 - Currently, no. The commands aren't set up in that way.

    @Gobiel - The latest dev version fixes that problem. Furthermore, Spout is causing issues that I can't seem to solve, and SpaceManiac isn't here to promote my changes so all hell is breaking loose

    the world is ending
  16. Offline


    What is better ? bPermissions or this one ? I have bPermissions but somethign like /spawn wont work .... how to use it with the Bridge ?
  17. Offline


    Removed spout, same issue.. Not allowed to use /permissions .. Not even in console. =/
  18. Offline


    maybe I'm just a noob but i can't seem to figure out the command to create a new group...
  19. Offline


    i am haveing the same issue as kriseike,

    my permissions still work, i just cant reload it.
    and everything worked yesterday, including it installed with spout.

    should i just try to reload the plugin and re-enter my permissions?

    anything that can be done to fix this would be amazing, until then i will just restart the server every time i make a permissions change
  20. Offline


    I just wanted to chime in here and say, I'm having no problems at all with this plugin.

    I'm running IndustrialCraft/Buildcraft modded to bukkit and everything with this plugin worked with all my other plugins using the superperms bridge for Elevator/AdvancedMobs/AnvancedWolves/Essentials, and the new superperms for MV2. The superperms bridge is working perfectly, my users are happy with all their new stuff from essentials I never let them have before, and all is well in Aox-Server-Land. Thanks to SpaceManiac for this awesome perms plugin, and especially to krinsdeath for keeping it updated as best he can!

  21. Offline


    I found a fix :) some how when i was backing up my server something got a little funky :)

    i all did was delete the folder and have the .jar remake it then copyed back over my config

    worked like a charm awesome plug-ing

  22. Offline


    Any chance the plugin will support the ability to select the default group in the next release? I do not want all newcomers to be a member of "Default", I want to stick them into a group with a name that means something on my server (and I do not want to have to do this manually).
  23. Offline

    Cosmic Break

    Whenever a new player joins my server, theyre not put in the member group. theyre put in some null group that has no permissions. i dont want that.

    heres my config - http://tinypaste.com/25849

    can anyone tell me what the problem is?

    edit: ignore pearmissions, somehow made that typo when copy/pasting?
  24. Offline


    Damn, thought we had till 2012. If the Aztecs would have known about BukkitPerms!
  25. Offline


    Try PermissionsEx... it will statisfy you. At least it did after i tried hard with this for 10 hours.
  26. Offline


    please make the converter for 3.x and 2.7
  27. Offline



    Thanks so much for being awesome and pushing out a build of PermmissionsBukkit and keeping it updated.

    As you said above, Spout seems to be causing the reload issues....they are still present in the latest Spout possible right? If you have done so, could you please consider releasing the build of PermissionsBukkit that fixes the issue (read about massive re-write so idk there)

    That or list out what one needs to do to potentially fix it. I am learning the BukkitAPI and starting to learn the Spout API so I am not adept in it yet but am willing to try :)

    EDIT: To everyone above having issues with PermissionsBukkit....I can do my best to help you folks out :)
  28. Offline


    Hello, I need your help, if I want to install new permission for Default group I write like this:
    permissions.build: true
    or how? Cuz if I write like this in game after /perm reload I have a error. please help!
  29. Offline


    Here is a template for a config.yml for PermissionsBukkit

    I customized it a bit for you so to make it easier to understand. I hope that this helps you and others out.

    One a side note....I recommend only allowing your members (registered users above) to build on your server...this kind of setup would make a grief even easier to do (of course this also depends on your plugins you use on your server).

    # Listing of users and their groups/individual permissions
    # Members
       (replace with users that are members):
            - member
    # Moderators
        (replace with users that are mods):
            - mod
    # Administrators
        (replace with users that are admins):
            - admin
    # Listing of groups and what permissions are set per group
    # Guests/Non-Members
                    permissions.build: true
                    lwc.protect: true
    # Members
                 - default
    # Moderators
                 - member
    # Administrators
                 - moderator
  30. Offline


    I have spent the last several days using my spare time trying to gather all the permission nodes for the several plugins i use . Sorry this is long, but some things are still not very clear to me even though I have been doing a lot of reading,
    - Do I need to list each permission, in every group then set it to true or false? It never really explains that part maybe a more detailed explanation of what the true and false are doing for us would help.
    - Why are users back in with the group’s permissions YML? If there is an error writing a new user I don’t like having both files corrupted and losing group settings and for sharing permissions with other servers I dont want to give my playerlist ?
    - As I read I get conflicting info about using wildcard * nodes, i read you can't use them and then the 1st one they give you is permissions.* ?! so you can use them but under what circumstances?
    - Favor, could we have something short like /permset <Name> <group> to set a players group please?
    - Idea - Now that we have a more ‘official’ permissions system is anyone interested in working on a GUI app for setting them? i understand it would be great if plugin writers followed a rule so all nodes were in 1 place to capture by the GUI... Players names could appear in rows and the groups could be arranged in columns across the top with check boxes? The permission nodes could look the same. Simplified Diagram below
    Player Name Default Member VIP MOD Admin
    DrDoofenshmirtz □ □ □ □ √
    Perry □ □ √ □ □
    Candace □ □ □ √ □
    Ferb □ √ □ □ □
    NODES Default Member VIP MOD Admin
    commandbook.rules √ □ □ □ □
    commandbook.motd □ √ □ □ □
    commandbook. kick □ □ □ √ □
    commandbook. setspawn □ □ □ □ √

    Formatting lost at upload but you get my drift
  31. Offline


    PermissionsBukkit doesn't have the ability to set a default group, you actually need a group called 'default' for people to be added into automatically upon first connection. :)

Share This Page