[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

    Celtic Minstrel

    SuperpermsBridge simply makes plugins that require the old Permissions API compatible with the new Superperms API. If you're using PermissionsBukkit, this means that they will see the permissions specified in your PermissionsBukkit config.yml.

    You're forced to name it "default".
  3. Offline


    Here's to version 1.2 allowing ANY group to be considered default *raises glass*.
  4. Offline


    Yeah.. I think the issue lies with things like MCDocs... and others that rely on pulling some info variables that are not necessarily related to "Permissions" but still are being provided by the legacy permissions systems, group memberships, legacy prefixes, suffixes, and maybe other things that just are not in the bridge beyond just "Basic Legacy Permission Nodes"...

    I just assign permissions in the order of newest permission system to oldest...if it works 100% in the new system, or new bridge.. it can be removed from legacy.

    I'm just suprised that you CAN run both simultaneous... logically it would seem to conflict... If you think hard about everything you have experienced as a server admin, maybe its more of a situation like the one when the same plugin is accidentally loaded twice and therefor answers twice.. duping itself in everything it does.. but in this case its 2 DIFFERENT plugins returning the same info for the same purpose.

    IE... The incompatible plugin doesnt receive the answer from the bridge it needed, but the legacy permissions does send it.. now the plugin has the answers it needs and proceeds merrily along its way without puking all over the console.

    I don't know what would happen if conflicting things were returned when the plugins answer... ie.. both a true and negated permission.. but based upon my own historical understandings, I guess it would be a first come, first serve type thing..

    I'm just glad that this works... my initial reaction was that it could have its own issues... but seems to work for the admin who knows the legacy stuff + new stuff.. that admin can be universal.

    I still feel kinda sorry for the new guys.. it is hella confusing... but no one said server administration was for newbs anyway..

    It seems like only a small flesh wound.. time will heal it. ya know?

  5. Offline


    isn't where a way to use the bridge the other way round?
    to use permissions3 instead of superperms
  6. Offline


    hi guys,

    i'm using worldedit and want to give admins in world "rpg" all permissions but only superpickaxe in "world".
    how do i set up my config?tried this one, but doesn't work^^ :
                    permissions.*: true
                    superpermbridge.*: true
                    worldedit.*: false
                    worldedit.superpickaxe: true
                    permissions.*: true
                    superpermbridge.*: true
  7. I'm was using permissions 3.x and essentials. I've now switched to bukkitperm and since then even though I have the correct node for the essentials.help command I'm getting an 'error:null' error. Is this something to do with Essentials compatibility with Bukkitperm or vice versa?........
  8. Offline


    Do you also have the Superpermbridge.jar to bridge Essentials over to PermissionsBukkit? Essentials does not yet support it by default.

    In my experience so far with the bridge, you need to prefix your permissions nodes with "superpermbridge." if you wish to reference any plugins that are hooking in that way. The following example SHOULD give:

    All admins access to all permissions commands.
    Admins of WORLD access to all commands of all plugins that tie in through SuperpermBridge.jar (just like '*' in 3.1.6 would work).
    Admins of RPG access to only worldedit.superpickaxe.

                permissions.*: true
                    superpermbridge.worldedit.superpickaxe: true
                    superpermbridge.*: true
    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 17, 2016
  9. Aye, got both PermissionsBukkit v1.1 (jar) and SuperpermsBridge v1.2 (jar) is there something I'm missing with Essentials? Or maybe something else? All I know is that the help command is obviously not retrieving the allowed commands from bukkitperm, which I'm assuming is something to do with the compatibility etc.....
  10. Offline

    Celtic Minstrel

    Nope. I don't think it's possible. What is possible is for Permissions 3 to update so the bridge is not needed.
  11. Offline



    I set my conf like that:

                essentials.home: true
                essentials.kit: true
                mchat.prefix.ce: true
                permissions.build: true
                    egg.renade: true
                    factions.create: true
                    essentials.home: false
                    essentials.kit: false
                essentials.give: true
                essentials.item: true
                    essentials.give: false
                    essentials.item: false
            - default
    It's a small portion of the config.

    The problem: When a default user takes a portal and go to the pvp world. The new permissions under pvp node don't apply! But If he deconnects then reconnects in pvp world, the permissions for pvp will apply! But same as before, if he returns to default world, he keeps the pvp permissions.

    Thanks for your help!
    (using CB1060, with multiverse 2.0)
  12. Offline


    ok this is wierd!
    using 1.1
    using cb 1060

    all permissions prevously set work BUT us admins ops and even the console dont have permission to edit permissions anymore!!!!
  13. I cannot get this to work, I think its just a problem with users... not sure though. Here is my config.yml: http://pastebin.com/9KW5vXtM
    Here is the server log:
    When I go into the game, the permissions don't seem to be working for me and it also seems as though it is just using everything as if it is just permissionless!
  14. Offline


    Okay I have made the attempt at switching from Permissions 3.1.6 to this, whoa what a headache learning to do the same thing in a "slightly" different format. Anyway I got permissionsBukkit and the super bridge thingy (lol) I re-wrote my ENTIRE groups and users (not much to change in users) files from 3.x and FINALLY got the server started...only now its saying it cant load permissionsBukkit, so not being a "coder" or have any knowledge on writing Java or anything like that I thought "hmm maybe I put it in the main server root folder?" and everything seems to have loaded and running fine. I still have 3.1.6 running also because of some plugins but it says in the server console for most plugins it has loaded "2.7.7" which is obviously the super bridge thingy, BUT is this the correct way of doing it? I read you are supposed to put permissionsBukkit in the "plugins" directory but it wont load in there for me and says something about "not allowed to map here" with a SEVERE warning. If this IS the way its meant to be can somoeone make it more clear on the first page? Also it says in the title its version 1.1 but at the top of the first post it says current version 1.0? And I saw someone mention a version 1.2 and that 1.1 is buggy? Can someone tell me whats up with all of that and if I'm making no sense just tell me to go away lol. Thanks in advance!
  15. Offline


    @SpaceManiac please help this is rather major

    is no one else getting this problem?
  16. Offline


    Nevermind about my problem lol I figured it out. I had some wrong text in the permissions file. @mrgreaper I am about to run my first test using 1.1 and running #1060 also so I will let you know if I run into the same problem
    mrgreaper likes this.
  17. Offline



    It would be awesome if you could do 2 different yml files.
    One for the groups and the other for the users.
  18. Offline


    thx dude!!
    but i still see a little problem. in ur example admins in rpg can only use superpickaxe (that's okay and what i wanted) but additionally they should be able to use all the other stuff (used by permissions 2/3) except the other worldedit commands.
    i'll give it a try when i'm at home... maybe i'm having errors in reasoning. :p
  19. Offline


    @mrgreaper Okay I tried it out and all I can do is reload. Every other command I try comes back with
    [permissions] user/group does not exist
    And that is all in red. I have only just started migrating from permissions 3.1.6 but as far as I can tell I have everything set correctly.
  20. Offline


    I am missing the /permissions group delete GROUPNAME command.
    Please add! Great plugin!
  21. Offline


    When I try to use /help even though I don't have the permissions it says 'I'm Sorry, Dave, But I Cannot Let You Do That'
    is there any way to change or remove the message?
  22. Offline

    Celtic Minstrel

    That's nothing to do with PermissionsBukkit.
  23. Offline


    Hey Guys,
    is there a way to restrict the /perm player setgroup xx xx command`? so my moderator can force themself to admin ... :(

    Help Plz!
  24. Offline


    @mrgreaper sorry I cant get it working at all, taking permissionsBukkit out till I can find an easier to understand tutorial on it, good luck!
  25. Offline


    Don't give those users access to Permissions.player.setgroup (or permissions.* etc. etc.)

    For this, you would need to list the permissions node for each individual plugin and exclude the Worldedit stuff that you do not want them to access (instead of giving them superpermbridge.*).

    You could also try this, though I'm not sure if it'll work:

                permissions.*: true
                    superpermbridge.*: true
                    superpermbridge.worldedit.*: false
                    superpermbridge.worldedit.superpickaxe: true
                    superpermbridge.*: true
    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 17, 2016
  26. Offline


    "A minimalistic bridge from Permissions 3.0 to Superperms is available as a separate plugin, which does not depend on PermissionsBukkit."
    So you can use Permissions 3.+ with this? And only edit the permissions in PermissionsBukkit?
  27. Offline


    I think what this means is that you can choose to use Permissions 2/3 in tandem with PermissionsBukkit (though you would have to maintain 2 separate configs). Any of the plugins that rely on Perms 2/3 will find and hook into that, while any plugins that rely on PermissionsBukkit (like MV2) will find and hook into that.

    To make the transition a little easier, you can simply use the Superpermbridge.jar which pretends to be Perms2/3 and maintain a single config in PermissionsBukkit. I am currently doing this and have only found a few small snags.

    Interesting, I did not have any trouble with the node. Are you using 'superpermbridge.essentials.help' in your PermissionsBukkit config?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 17, 2016
  28. Offline


    bump! help
  29. Offline


    Permissions in multi worlds don't work. Players keep the same permissions until the permissions config is reloaded
  30. Offline


    So if a plugin needs Permissions 3.1.6, it's enough to have superpermbridge installed? Or do you need Permissions 3.1.6 installed, and superpermbridge only transfer the permissions to PermissionsBukkit?
    I am confused as you can see xD
    Sorry for bother you btw.
  31. Offline


    Alright I just tested the github source and it fixes the multi world issues. Please releases this build!

Share This Page