[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

    SpaceManiac

    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.

    Features:
    • 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.

    Configuration:
    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:
    Code:
    users:
        ConspiracyWizard:
            permissions:
                permissions.example: true
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: false
        admin:
            permissions:
                permissions.*: true
            inheritance:
            - user
        user:
            permissions:
                permissions.build: true
            worlds:
                creative:
                    coolplugin.item: true
            inheritance:
            - default
    messages:
        build: '&cYou do not have permission to build here.'
    

    Permissions:
    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:
    Code:
    server.basics:
        children:
            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:
    Code:
    server.basics:
        description: Basic permissions for My Cool Server.
        default: true
        children:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    server.admin:
        description: Admin permissions for My Cool Server.
        default: op
        children:
            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:
    Code:
    da-name-format: '+prefix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+name&f: +message'
    mchat:
        prefix:
            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.

    Downloads:
    Current Version:

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

    [​IMG]

    Changelog:

    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

    Flatliner

    Something else I've found (don't know if it's been mentioned already) but if I do /reload in the server, when it completes everyone loses their permissions until they reconnect to the server. That's with dev build 18 from jenkins.
     
  3. Offline

    krinsdeath

  4. Offline

    Luke.Handle

  5. Offline

    br0ad456

    i put it in my plugins, but i have no files appearing. i'm very confused on how this permissions work

    theres no clear set up instructions anywhere. :/

    where the hell is the config file!!

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

    ACStache

    @br0ad456 I believe it's the permissions.yml file in the server folder. follow the instructions for configuration and using the root permissions.yml spoilers in the OP
     
  7. Offline

    br0ad456

    but where is that yml file. i dont have one

    this post is so unclear, i have no idea where my config file is

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

    ACStache

    where did you put your craftbukkit.jar file? in that place, should be a file named permissions.yml
    that's your 'config file' for this plugin.
     
  9. Offline

    br0ad456

    there no permissions.yml there. the permissionsbukkit is in the plugins folder and my craftbukkit.jar is where its ment to be. this is so frustrating, iv had to shut my server down
     
  10. Offline

    Flatliner

    Sorry, when I said last build posted up I actually meant on the jenkins server, my fault for not specifying . I'm using build 18 which was the latest build on the jenkins server yesterday. All the quirks I've found have been with that build.
     
  11. Offline

    ACStache

    what version of craftbukkit are you running?
     
  12. Offline

    br0ad456

    latest RB
     
  13. Offline

    ACStache

    can you confirm it's build 1000 then? the permissions.yml file should auto generate... if you're using any build before 1000, it won't work
     
  14. Offline

    br0ad456

    what should i have in my plugin folder PermissionsBukkit or superpermsbridge or both?

    definatly on build 1000

    i use verygames to host my server and ftp into it and theres no actuall craftbukkit.jar i can see anywhere but it still runs and i updated it though the verygames user panel

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

    ACStache

    @br0ad456 idk what to tell you then. if there's no craftbukkit.jar then something isn't right :p lol. what do you see when you ftp into it? are you allowed to upload stuff to it/pull stuff down from it?
     
  16. Offline

    krinsdeath

    @br0ad456 - There's no need to post so much. Just state your problem and someone will get to it eventually. I'm not even sure what your problem is anymore, because you've posted almost 2 pages of replies.

    @Flatliner - I'm unable to replicate any problems with /reload or /perm reload. Are you running both PermissionsBukkit and another permissions plugin (including SuperpermBridge)? I've tried everything I know and can't find any problems. After reloading, try doing "/perm dump <player>" and let me know the output?

    @Flatliner - No idea, bud. I've got my server running, I've tried every variation I can think of as far as reloading and trying to break permissions that I can think of, and it doesn't work. Are you using multiple worlds, with complicated sets of inheritance? I don't have anything to really base my random guesses on.

    @Devices - The post explains (in rather short order) exactly what you need to do to configure permissions. While I'll admit that the SuperpermBridge isn't very well documented, it is explained in the original post. Because the new permissions system doesn't inherently define wildcard nodes ("*" nodes), you need to expressly indicate that superpermbridge should handle them: "superpermbridge.essentials.*: true"

    The superperm bridge isn't perfect; it's intended to serve as a communications bridge while the various plugins update to support Superperms. My only suggestion is to read the various plugins threads regarding which ones support superperms (and thus can utilize PermissionsBukkit without superpermbridge) and which ones do not. To my knowledge, Essentials, WorldEdit and BigBrother do not support superperms, and as such will require the use of the superpermbridge prefix for their corresponding [wildcard permissions] nodes.

    Code:
    groups:
      users:
        permissions:
          worldedit.wand: true
          superpermbridge.worldedit.navigation.*: true
          essentials.motd: true
          superpermbridge.essentials.mail.*: true
    
    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Sep 9, 2018
  17. Offline

    Flatliner

    @krinsdeath I'm running superpermsbridge but no other permissions related plugins. A /perm dump just shows me having zero permissions. If I leave the server and reconnect I have all the permissions back again.
     
  18. Offline

    Devices

    This plugin or whatever you want to call it is very unclear. The OP just throws you some files and says go figure it out yourself.

    I've installed both PermissionsBukkit and SuperPerm, set up the permission in the config and nothing happens. I can move myself from admin to default and I still have all admin right.

    Yes, I use build 1000, permissionsbukkit 1.1 and superperm 1.2 before anyone asks.

    config.yml:

    Code:
    users:
        Devices:
            permissions:
                permissions.example: true
            groups:
            - default
        Dirtyklingon:
            groups:
            - Mod
    groups:
        default:
            permissions:
                permissions.build: false
                spoutessentials.joinmessage: true
                spoutessentials.leavemessage: true
                spoutessentials.playmusic: true
                spoutessentials.playgmusic: true
        Admin:
            permissions:
                permissions.*: true
                instabreak.*: true
                worldedit.*: true
                bigbrother.*: true
                essentials.*: true
            inheritance:
            - Mod
        User:
            permissions:
                permissions.build: true
            inheritance:
            - Default
        Mod:
            permissions:
                permissions.build: true
                mobdisguise.*: true
                magiccarpet.mc: true
                magiccarpet.ml: true
                instabreak.toggle: true
                permissions.*: true
                essentials.*: true
            inheritance:
            - User
    messages:
        build: '&cYou do not have permission to build here.'
    
     
  19. That's where you can define parent permissions, but this plugin generates it's own config.yml at \plugins\PermissionsBukkit\config.yml That's the file you want to add your groups/users to.
     
  20. Offline

    Flatliner

    Has anyone else found that when issuing a /permissions reload it doesn't pick up any changes from the root permissions.yml file? I have a number of permissions in there and it's annoying having to reboot or /reload the server whenever I make changes to that.
     
  21. Offline

    SpaceManiac

    It's not intended to, the root permissions.yml is a CraftBukkit file and can only be reloaded via a /reload.
     
  22. Offline

    Master_Rudik

    I can't seem to get the wildcard in SuperPermsBridge to work at all...

    I'm right now trying to give my admins all the WorldEdit commands, but everything else I have tried for other plugins also doesn't work. Here is what I've put in my config as a last resort to attempt to enable WorldEdit for my admins:
    Code:
                superpermsbridge.worldedit.*: true
                superpermsbridge.worldedit: true
                superpermsbridge.WorldEdit: true
                superpermsbridge.WorldEdit.*: true
                superpermsbridge.WorldEdit.worldedit: true
                superpermsbridge.WorldEdit.worldedit.*: true
    Still, my admin group cannot use any WorldEdit command. I've also tried with the BlocksOnGlass, CommandBook, KiwiAdmin, WorldGuard, MyWarp, and MyHome plugins (some were attempt at subnodes, e.g. superpermsbridge.mywarp.warp.basic.*: true).

    Here's my full config.yml (All of the boi.whatever, bof.whatever, and so on are my last-ditch efforts to get BlocksOnGlass working. It was rather tedious. Please don't make me do that for WorldEdit)

    I am on the build of PermissionsBukkit from this post: http://forums.bukkit.org/threads/ad...-groups-plugin-1000.26785/page-19#post-547082
    I am on build 1.2 of SuperPermsBridge.
    I am on CB 1000.

    Much appreciated.
     
  23. Offline

    br0ad456

    im using the example config file and its not letting me build :/
     
  24. Offline

    Flatliner

    @krinsdeath Hmm. I'll try removing everything in my permissions file and see if it still does it, I'm keen to find the cause as it's pretty annoying. I do have some inheritance going on and multiple worlds but the inheritance is fairly simple (eg. rank 3 inherits from rank 2, which inherits from rank 1).
     
  25. Offline

    SpaceManiac

    It's actually 'superpermbridge' without the S (confusing, I know), but the latest WorldEdit/CommandBook/WorldGuard do not require the bridge.
     
  26. Offline

    krinsdeath

    @Master_Rudik - I believe the prefix requires superpermbridge, not superpermsbridge. I can't say this with 100% certainty, but I (personally) was able to get worldedit's entire command set working with 'superpermbridge.worldedit.*: true'.

    @Flatliner - Try putting "debug: true" at the top of your PermissionsBukkit's config.yml. When you reload the server, put a pastebin of the output up and link it here (or PM it to me, if you're worried about user privacy). It could be something wonky with another plugin that I'm not able to see. Also, a copy of your config.yml itself would be good.

    @br0ad456 - You need to add yourself to the config file as a user with admin rights in order to build, or change the default "permissions.build: false" to true for the default group. Without knowing [anything about] the entirety of your problem, I can't even make a guess as to what the cause of the problem is. Ideally, put up a paste of your config.yml, plugin list and (if possible) a log of your startup sequence (on pastebin), and I'll try to help.
     
  27. Offline

    Master_Rudik

    Huh. Works now.

    I read the commands off of the changelog, so that's probably why I got confused. You may want to change it, as it currently displays all the commands as 'superpermsbridge.whatever':
    Show Spoiler

    Changelog:
    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 'superpermsbridge.*' and 'superpermsbridge.pluginname', now supported are 'superpermsbridge.plugin.*', 'superpermsbridge.plugin.subnode.*', and so on.
     
  28. Offline

    br0ad456

    ok ill do that in sec, can i ask though should i have permissionsbukkti and superperms?
     
  29. Offline

    Jinux

    Bumpity.

    Still can't use the /permissions command when both PermissionsBukkit and SuperPermBridge are enabled
     
  30. Offline

    Flatliner

    @krinsdeath Right, I've figured out the cause. It seems to be Spout. If I remove it, I retain my permissions after a reload. If I put it back in then it breaks.

    Tried using debug:true to see if anything weird was happening and nothing seems to be, it's detecting the world I'm in both before and after the reload but after the reload it doesn't give me my permissions. This is with a bare bones config file as well, it looks like this:

    Code:
    debug: true
    users:
        flatliner_:
            permissions:
                superpickaxe.use: true
            groups:
            - Admin
    groups:
        default:
            permissions:
                permissions.build: true
        Admin:
            permissions:
                permissions.*: true
            inheritance:
    messages:
        build: '&cYou do not have permission to build here.'
    
     
  31. Offline

    krinsdeath

    Weird, Spout actually works properly for me. I'm using an older version (build 43, as opposed to the latest build 69), but it works fine. I'll do some testing and see what (or if) the issue is in Spout, and if it is I'll see about how to fix it. Thanks!
     

Share This Page