[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


    No, it means doing it properly WILL work. As I also stated, trying to use it across the board permissions2/3 style will likely not work and that is probably where the bulk of the problems are coming from, but if you follow each plugin's guidelines it can be made to work extremely reliably. Stop spreading FUD.
  3. Offline

    Makil Heru

    I can't seem to find the command that lets default users press buttons. Whats the command to allow them to do that?
  4. Offline


    If, by doing it properly, you mean downloading half a dozen plugins that APPLY the functionality, as opposed to doing it manually PER node (which works out of the box) is what you mean, then yeah, he can go download superperms and permbridge till he is blue in the face, and yes, they will all work fine. HOWEVER, your point of commenting to tell me i'm wrong about *'s is not an answer to his question and is asinine.

    The post WE are talking about is issues with (1) Where his permissions need to be and (2) the format for them. Not where the *'s go, or whether or not they should be used. I made a passing comment about disliking them and he asked why, and I answered. End of topic.

    Now either spend more time answering the backlog of pages of people asking for help or go away. Those of us who post on this thread to help others are busy and have more important use of the board space you are taking up.
  5. Offline


    When I see people repeatedly spreading FUD I will call them on it whether you like it or not. Some may find the dispelling of myths helpful, but if you have no time for me feel free to ignore me.
  6. Offline


    To the rest of the people who are waiting for help, or to the any of a dozen or more who's issues I've solved in the last week, I apologize, I won't be checking the forum again until I am aware Heliwr doesn't have his/her face glued to his/her monitor waiting to just repost garbage as a counter to anything that comes out of my mouth before actually understanding the conversation they are entering. Unless they opt to actually say something useful and help you out, in which case I'm glad I'm not the only one that offers to pour over others config over and over again for once to get them up and running.
  7. Offline


    Thanks again for the help. What I have done is... Member's base permissions, inherit to the ranks above, for every world. Members permissions for the creative world should inherit to the worlds above that. The problem I am having is with that, the inheritance. Could you format my config.yml correctly for me? Or is it only the word - worlds: and world: that are different causing problems? Thanks again!

    Edit: Testing the config.yml with the world(s) error fixed. I'll post again when with results! That fixed a problem I was having with Administrator inheritance. But the commands from Member: Permissions: still aren't inheriting.

    Another Edit: Updated the link with my latest config.yml file :)
  8. Offline


    I'll let heliwr answer that one as they seem opinionated enough to do so.

    I see a couple of things and am moving into a pm with you to talk about them. The trolls are restless.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jul 14, 2016
  9. Offline


    Is this plugin going to be developed further to add features? OR should I find another plugin that will suite my needs?
  10. Offline


    I would imagine its still under development since its compatible with the most recent cb
  11. Offline


    Heliwr, Galameth is right on all accounts, stop trolling and leave the guy alone. He helps out everyone here fixing our problems, he doesn't get anything out of that, but he still does it, so leave him alone.
  12. Offline


    I tried it and It still doesint work. Here is the new file : http://pastebin.com/g5vqY0Tz
  13. Offline


    He is NOT right on all accounts, his anti-* crusade is extremely ridiculous. If a plugin developer has defined a .* node it is almost certainly because he feels it is safe to use - contradicting that developer, especially with zero knowledge of the code, is idiotic and disrespectful.

    I commend galameth for wanting to help and dedicating so much of his time to do so, but I will not stay silent while he spreads lies and disinformation. Examples of plugins with * nodes that work perfectly fine even with inherited subnodes are:
    nocheat.checks (no * in this one, but it is similar in that it is a collection of subnodes)

    These are just the ones I'm using currently, and many other superperms-compatible plugins have metanodes defined that work exactly as advertised. Suggesting they might not work if used and that they should be avoided at all costs is irresponsible and doesn't serve anyone. Rather, he should be encouraging users to read the documentation for their plugins and follow the developers' guidelines.

  14. Offline


    No, he is saying the right thing, you don't need * nodes in PermissionsBukkit because of the new system, as clearly said. He isn't spreading lies and disinformation (is that even a word?). They make work perfectly fine, but they aren't the correct way to do it. You should be the one reading the developer's guidelines for PermissionsBukkit.
  15. Offline


    Hi, is there anyway for this to hook into essentials? because I have Permissions Bukkit and Essentials buy only the Essential Ranks kick in
  16. Offline


    Hey i added someone to a group and they still cant do anything. How do I fix it?
  17. Offline


    They are the correct way to do it if the plugin developer makes it the right way to do it, the PermissionsBukkit documentation does not say you should not use nodes defined by a plugin (read the 'Where are my * nodes?' section of the FAQ in the OP) - and good luck using something like worldguard without it.

    You need to edit the Essentials config to tell it to use superperms.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jul 14, 2016
  18. Offline


    Well good morning Heliwr!
    This is the second time you have given evidence that you have no clue as to either what I am talking about nor the conversation you are injecting yourself into.

    At no point, ever, did I say the *' nodes in plugins do not work themselves, I have IMPLICITLY stated that "permissionsBukkit" fails to read them properly. HENCE WHY I'M POSTING IN A PERMISSIONSBUKKIT THREAD and not going around to every plugin and posting that their *'s don't work.

    You absolutely under no circumstances NEED a global setting, and, (now read carefully because you are going to quote this later) any plugin that REQUIRES you to set a global level permission without giving you the option for individual node control is ridiculous, dangerous, and lazy. Lazy Lazy Lazy.

    I have specifically stayed here, and my main area is PERMISSIONSBUKKIT and has nothing do do with the plugins used themselves OTHER THEN PERMISSIONSBUKKIT.

    So your stance that i'm on an "anti-global.node" crusade is cracked. I implore you, yet again, to actually read first before making an assumption based off of one or two replies you've seen me make. Herp.

    As to the rest, it's a new day and hopefully a good one for getting PERMISSIONSBUKKITs up and running!

    Looking over it again here shortly and I'll see what else might be causing issues. Also, did you happen to grab or have EssentialsSpawn?
  19. Offline



    ive a qeustion.
    first of all im new to permissions but this is what i did:
    i filled my config.yml with this: http://puu.sh/6Nz0
    my permissions.yml is empty (cant find anywhere what to put in there)
    Only thing is when i go ingame and try some command it says: "you do not have promission for that".

    Does anywone know what i do wrong here?
  20. Offline


    From whats viewable in your post your users are good, but we can't see the rest of the actual config. Pastebin or CODE tags?
  21. Offline


    I am not aware of any plugins that don't allow individual node control, but there is nothing wrong with using metanodes when they are made available. And you will probably say taking advantage of them is lazy too, but since when is being efficient with your time and effort a bad thing?
    As for never needing metanodes - Great, I would love for you to tell me how to manage the worldguard.region.flag.own.*, worldguard.region.addmember.own.*, worldguard.region.info.*, and other similar nodes using only individual node control on a high traffic server.

    I have no problem with you helping people, but the fact that you are so active helping people in this thread should place a greater responsibility on you to not present incorrect information. Metanodes when used properly according to the individual plugins' documentation are interpreted properly by PermissionsBukkit (at least the recommended 1.2k version I am using), and attempting to scare people away from using them for misguided reasons is wrong.
  22. Offline


    Ok, let me take time away from what i'm working on, yet again, and ask you this.

    Why do you use *'s?
  23. I want to give worldedit permissions to my mods. All of them. However, when was the last time you ever wrote down twelve pages of permissions, when doing worldedit.* or worldedit.all would be a HELL of a lot less typing and also a lot smaller of a file to read and write to.
  24. Offline


    In the case of worldguard, because I pretty much have no choice. For some others, what you probably call laziness and I call efficiency - why would I assign 50 individual essentials nodes to my admins when I intend them to have all of them and essentials.* does it in one node?
  25. Offline


    How about as a rule of common sense every time you set up a (non-game) server? How about every time you do any form of IT infrastructure? How about every time you open a Linux environment? How about every time you set up a user database? How about every time you install a security system? And how about every time you work with a permissions list that involves commands that could wipe your server?

    Also, that's why you create groups. you type it once and apply the mods to that group. derp. That is a perfect example of the "It's there and I'm lazy" mindset.

    Sure, if you had to redo it every day and for every player and for every command for every world. But you don't. you only have to do it ONCE. And people are too lazy to do even that.

    Because you are not doing it for each individual players permissions set. you are doing it ONCE per group.

    Though I dispute that worldguard requires it, I haven't looked at it to see if it offers individual nodes, so I cant.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jul 14, 2016
  26. Offline


    there is my whole code. Ive red the whole wiki i just dont understand what im doing wrong...
  27. It's still a long list of stuff to type.
  28. Offline


    Im using PermissionsBukkit 1.2k and i have a default group...

                permissions.build: false
                group.default: true

    However this group can open chests?
    How can i deny this group from opening chests?
  29. Offline


    I just tried Still didn't work....
  30. Offline


    Regardless how often I am doing it, it is unnecessary work and I don't buy that either is more or less secure under the right conditions - I know what nodes are included, check regularly with perm dump, and only assign high level metanodes to my admins who are trusted enough to have shell access to my server in any case. Call it lazy if you want, but if someone wants to be 'lazy' with their time that is their right and your scaremongering is an attempt to falsely coerce users to your preferred method. If your concern is that it is less secure then say that, but stop saying it doesn't work when clearly it does.

    Regarding WorldGuard, it can be done using individual nodes by explicitly naming each region - a difficult task when players add dozens of new regions every day.

    I don't think you can prevent players from accessing chest with PermissionsBukkit alone, you probably need something like LWC or WorldGuard.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jul 14, 2016
  31. Offline


    I did say that. I also say it's my opinion each time I do say it.

    Scaremongering is hardly what I'm doing. It may be perfectly acceptable to YOU to use such a function, but this thread is for the majority. For the people who have no idea what any of this means. If you were standing before a programming instructor they would throw you out of class for suggesting global variables for every single thing you try to code. Same here. People should NOT be using global variables for every group. Which they are. It's not just a case of "admins" only or "high level players" only. It's getting used in every group, some groups, no groups at all, it just being used per player.

    Good for you that you maintain your permissions so well, excellent that you regularly check who can do what, but tell you what, of the last 200 or so people on the thread? Only about 6 of us realize we can check that. And even less know that they should ONLY assign such a function to admins/owners.

    And you keep saying it over and over again: Under the right conditions.
    A gun is safe under the right conditions.
    A nuke is safe under the right conditions.
    Nutmeg is safe under the right conditions.

    All are just as equally deadly under the wrong conditions.

    If any of the configs here were "under the right conditions" they wouldn't be here for help because nothing they do works.

    That's akin to saying "The secret command that wipes everything is safe as long as noone knows it exists"

    Yes, indeed it is. But it only hurts once.

Share This Page