[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

    Deathlysteve-

    yeh its ok i ended up fixing it... the problem was the plugin 'Text Wrap"...
     
  3. Offline

    dxwarlock

    perhaps I'm missing something here, was using perms 3.0, then pex, now this for the multiworld support.
    I know it doesn't use '*' as a permission like the others, so does this mean I need to go thru and add all 57 of our plugins root command like 'worldedit.*' for admins for access all commands?
    or is there a MUCH easier way to do this.
    adding new plugins, having to edit the permissions each time to add me to the 'usable' list to test it would be tedious and unneeded if there is an equal or equivalent to giving me '*' as in the others.
     
  4. Offline

    Kellis

    @Celtic Minstrel
    Unfortunately, this configuration also does not work.
    Code:
    users:
        Kellis:
            permissions:
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: true
                commandbook.give.*: true
                lep.sethome: true
                lep.home: true
                worldedit.*: false
        admin:
            permissions:
                permissions.*: true
                commandbook.*: true
                worldedit.*: true
            inheritance:
            - user
        user:
            permissions:
                permissions.build: true
                permissions.build: true
                commandbook.give.*: true
                lep.sethome: true
                lep.home: true
                worldedit.*: false
            worlds:
                creative:
                    coolplugin.item: true
            inheritance:
            - default
    messages:
        build: '&cYou do not have permission to build here.'
    UPD:
    I fix problem with commandbook, use commandbook.give: true, commandbook.give.other: true ect., not commandbook.give.*: true
    But still here problem with home plugin. Can you tell more easily what I need to do? I have not understood moment with that
    Code:
    The other option is to bug the LEPHome guy to support superperms (you can tell him it's as simple as doing "player.hasPermission(node)" if the permissions handler is null).
     
  5. Offline

    Darcion

    did no one read the FAQ or my posting? you have to use superpermbridge.jar and the "superpermbridge.*: true" node instead of '*'

    my configuration worked and i tried it without being OP
     
  6. Offline

    dxwarlock

    I tried that before posting the first time, why I was confused how to do it.
    adding "superpermbridge.*: true" didnt seem to do anything for me, giving my self only that permission, I had access to nothing at all
    Code:
    groups:
      Admin:
        permissions:
          'superpermbridge.*': true
    users:
      dxwarlock:
        groups:
          - Admin
    unless I'm doing it incorrectly.
    I have the SuperpermsBridge-1.2.jar and the PermissionsBukkit-1.2.jar
     
  7. Offline

    Deathlysteve-

    How would i make 3 of my players be normal in one world, but Admins in another world (we only have 2 worlds)?
    Ive tried to add the permissions to the group they are in (superpermbridge.* or watever)
    but yeah... can i use world permissions in the users section to accign certain GROUPS to certain PEOPLE in certain WORLDS? if that makes sense :S
     
  8. Offline

    decebaldecebal

    will the plugin work with WordRank if i install SuperPermsBridge also?
     
  9. Offline

    palz2015

    Excuse my noobdom, but really, how is this any better than Permissions by TheYeti (or, formerly, Nijikokun)? I understand that it's more universal being built-in by default, but how is it BETTER?

    I see it as just more to set up.
     
  10. Offline

    Kellis

  11. Offline

    hatchling

    groups:

    default:
    permissions:
    buildr.cmd.build
    buildr.cmd.globalbuild
    buildr.cmd.allowbuild
    buildr.cmd.wall
    buildr.cmd.wallx
    buildr.cmd.cuboid
    buildr.cmd.sphere
    buildr.cmd.cylinder
    buildr.cmd.airfloor
    buildr.cmd.top
    buildr.cmd.undo
    buildr.cmd.give
    buildr.cmd.clearinv
    buildr.cmd.location
    admin:
    permissions:
    permissions.*: true
    inheritance:
    - user
    user:
    permissions:
    buildr.cmd.build
    buildr.cmd.globalbuild
    buildr.cmd.allowbuild
    buildr.cmd.wall
    buildr.cmd.wallx
    buildr.cmd.cuboid
    buildr.cmd.sphere
    buildr.cmd.cylinder
    buildr.cmd.airfloor
    buildr.cmd.top
    buildr.cmd.undo
    buildr.cmd.give
    buildr.cmd.clearinv
    buildr.cmd.location
    worlds:
    creative:
    coolplugin.item: true
    inheritance:
    - default
    messages:
    build: '&cYou do not have permission to build here.'
    groups:
    default:
    permissions:
    buildr.cmd.build
    buildr.cmd.globalbuild
    buildr.cmd.allowbuild
    buildr.cmd.wall
    buildr.cmd.wallx
    buildr.cmd.cuboid
    buildr.cmd.sphere
    buildr.cmd.cylinder
    buildr.cmd.airfloor
    buildr.cmd.top
    buildr.cmd.undo
    buildr.cmd.give
    buildr.cmd.clearinv
    buildr.cmd.location
     
  12. Offline

    Kellis

    @hatchling
    you need : true and : false after each permissions, for example
    permissions.info: true
     
  13. Offline

    hatchling

    @Kellis still dont work

    Code:
    users:
        hatchlingduif:
            permissions:
                permissions.build: true
                permissions.help: true
                permissions.reload: true
                permissions.check: true
                permissions.info: true
                permissions.dump: true
                permissions.group.help: true
                permissions.group.list: true
                permissions.group.players: true
                permissions.group.setperm: true
                permissions.group.unsetperm: true
                permissions.player.help: true
                permissions.player.groups: true
                permissions.player.setgroup: true
                permissions.player.addgroup: true
                permissions.player.setperm: true
                permissions.player.unsetperm: true
                buildr.cmd.build: true
                buildr.cmd.globalbuild: true
                buildr.cmd.allowbuild: true
                buildr.cmd.wall: true
                buildr.cmd.wallx: true
                buildr.cmd.cuboid: true
                buildr.cmd.sphere: true
                buildr.cmd.cylinder: true
                buildr.cmd.airfloor: true
                buildr.cmd.top: true
                buildr.cmd.undo: true
                buildr.cmd.give: true
                buildr.cmd.clearinv: true
                buildr.cmd.location: true
            groups:
            - admin
       
    groups:
    
        default:
            permissions:
                buildr.cmd.build: true
                buildr.cmd.globalbuild: true
                buildr.cmd.allowbuild: true
                buildr.cmd.wall: true
                buildr.cmd.wallx: true
                buildr.cmd.cuboid: true
                buildr.cmd.sphere: true
                buildr.cmd.cylinder: true
                buildr.cmd.airfloor: true
                buildr.cmd.top: true
                buildr.cmd.undo: true
                buildr.cmd.give: true
                buildr.cmd.clearinv: true
                buildr.cmd.location: true
        admin:
            permissions:
                permissions.*: true
            inheritance:
            - user
        user:
            permissions:
                buildr.cmd.build: true
                buildr.cmd.globalbuild: true
                buildr.cmd.allowbuild: true
                buildr.cmd.wall: true
                buildr.cmd.wallx: true
                buildr.cmd.cuboid: true
                buildr.cmd.sphere: true
                buildr.cmd.cylinder: true
                buildr.cmd.airfloor: true
                buildr.cmd.top: true
                buildr.cmd.undo: true
                buildr.cmd.give: true
                buildr.cmd.clearinv: true
                buildr.cmd.location: true
            worlds:
                creative:
                    coolplugin.item: true
            inheritance:
            - default
    messages:
        build: '&cYou do not have permission to build here.'
    groups:
        default:
            permissions:
                buildr.cmd.build: true
                buildr.cmd.globalbuild: true
                buildr.cmd.allowbuild: true
                buildr.cmd.wall: true
                buildr.cmd.wallx: true
                buildr.cmd.cuboid: true
                buildr.cmd.sphere: true
                buildr.cmd.cylinder: true
                buildr.cmd.airfloor: true
                buildr.cmd.top: true
                buildr.cmd.undo: true
                buildr.cmd.give: true
                buildr.cmd.clearinv: true
                buildr.cmd.location: true
     
  14. Offline

    Mazeash

    Greetings, firstly thankyou for this great plugin, it works a treat for all my members. I do have an issue however that is really going to hold my server back and i'm hoping that someone could help me out with it.

    The problem I have is with new members, that is, members that haven't been added into any list yet. The way my server is set up is meant to deny all new members build rights until they have completed certain tasks, therein they will be promoted. Unfortunately when a new player joins, they aren't in any group therefore the restrictions I have set in place do not work, they all have build rights...

    My question is, how do I set up my config to make it so that every new player automatically gets added into a certain group?

    Any help on this would be greatly appreciated.
     
  15. Offline

    Celtic Minstrel

    @Mazeash – Every player who joins is automatically added to the "default" group. There is at present no way to change that.
     
  16. Offline

    Scandragon

    Simply put the restrictions on the default group and promote them to players after the tasks are completed
     
  17. Offline

    Mazeash

    Aah right, see I deleted the default group and changed it too "initiate" makes complete sense thats great thanks guys.
     
  18. Offline

    BoomBoomPoWn

    Uhm, when i try to see the groups via permissions group list, it says "Unknown console command. Type "help" for help."
    Can somebody help me? :D
     
  19. Offline

    afmiller

    I've tried different varients but I don't seem to be getting the syntax right for the bridge from 3.1.4 to this plug in. What kind of synatx do I need to put in the config file for the old commands?
     
  20. Offline

    Nipper

    If your using the superperms plugin aka the bridge plugin just put 'superpermbridge.' in front of the permission.

    Try making sure you have permission to use that command. If not try upgrading if your not using the newest.
    ''permissions.group.list' Is the permission for it.

    It could be a issue with commandbook not having a permission for those commands. As the /home is a dev build you might want to report it to them. I my self use the MyHome plugin. It has a little more meat to it. Like home invites welcome messages things like that.

    It may not be better. But it has what the bukkit team decided on a long time go. Maybe someone will do the same and use Permissions 3.x as a example. This way it will work as 3.x but still use the official permissions systemset by the Bukkit team.

    Download the 1.2 fix version you can set it that way with mutli world permissions.
    This is a example of group that I use for my creative world. It would not be hard to tweek it to use the way you want it to be. But bewarned giving admin flags on one world but not the other does not mean that still can't kick/ban/give items ect. To the other world.
    Code:
        SLB:
            permissions:
                permissions.build: true
            worlds:
                sl:
                    commandbook.give: false
                    commandbook.more: false
                    commandbook.clear: false
                    mchat.slb.SLB: true
                    mchat.lb.lmain: true
                    mchat.rb.rmain: true
                spawn:
                    commandbook.give: false
                    commandbook.more: false
                    commandbook.clear: false
                    mchat.slb.SLB: false
     
  21. Offline

    afmiller

    I get this error

    http://pastebin.com/tnqivDs8 using this syntax

    Jediman:
    permissions:
    permissions.example: true
    superpermbridge.essentials.afk

    fixed, forgot the : true part

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

    Nipper

    I was going to say. That errors is due to fomating issue. Meaning left off the : true or : false or to many or to less spaces.
     
  23. Offline

    blakefire

    Did I post this right? Also does the file need to be renamed to world.yml?
    Code:
    # PermissionsBukkit configuration file
    #
    # 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 all admin permissions. 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.
    
    users:
        blakefire:
            permissions:
            groups:
            - Admin
       lunardusk:
            permissions:
            groups:
            - Admin
       Danielle404:
            permissions:
            groups:
            - Admin
    groups:
        Guest:
            permissions:
                permissions.build: true
                myhome.home.basic.set: true
                myhome.home.soc: true
                scavenger.*: true
                gimme.gimme: true
                wolfpound.use: true
                mobRider.*: true
                rocketboots.boots.gold: true
                rocketboots.boots.diamond: true
                rocketboots.boots.leather: true
                rocketboots.boots.iron: true
                rocketboots.feather: true
                rocketboots.launchPlayers: true
        Admin:
            permissions:
                permissions.*: true
            inheritance:
        Artist:
            permissions:
                permissions.build: true
                gimme.gimme: ture
                magiccarpet.mc: true
                magiccarpet.ml: true
                DisposalChest.create: true
                DisposalChest.remove: true
                myhome.home.basic.set: true
                myhome.home.soc: true
                lockette.user.create: true
                iwolvesadoption.commands: true
                lockette.user.create.*: true
                worldedit.wand: true
                worldedit.wand.toggle: true
                worldedit.selection.pos: true
                worldedit.selection.hpos: true
                worldedit.region.faces: true
                worldedit.fixlava: true
                worldedit.fixwater: true
                worldedit.history.undo: true
                worldedit.history.redo: true
                worldedit.history.clear: true
                worldedit.region.set: true
                worldedit.brush.smooth: true
                worldedit.region.smooth: true
                worldedit.navigation.jumpto: true
                worldedit.remove: true
                mobRider.*: true
                xlevel.player.*: true
                worldedit.brush.clipboard: true
                worldedit.clipboard.copy: true
                worldedit.clipboard.paste: true
                worldedit.region.stack: true
                residence.create: true
                worldedit.region.replace: true
                scavenger.*: true
                worldedit.region.walls: true
                worldedit.clipboard.flip: true
                worldedit.clipboard.cut: true
                admincmd.tp.to: true
                admincmd.player.list: true
                admincmd.player.msg: true
                rocketboots.boots.gold: true
                rocketboots.boots.diamond: true
                rocketboots.boots.leather: true
                rocketboots.boots.iron: true
                rocketboots.feather: true
                rocketboots.launchPlayers: ture
                worldedit.generation.forest: true
                worldedit.region.overlay: true
                war.player: true
                war.warp: true
            worlds:
                creative:
    
            inheritance:
    messages:
        build: '&cYou do not have permission to build here.'
    
     
  24. Offline

    Celtic Minstrel

    No.
     
  25. Offline

    decebaldecebal

    still didn't answered my question:does it work with WordRank?
     
  26. Offline

    Chugger

    I didn't see this written anywhere. Are you sure that's correct?
    <p>
    I haven't been able to place or destroy any blocks, even with allpermissions or even with giving permissions right under my name, or removing allpermissions or removing superpermbridge etc....etc.... I get no errors and have an open ticket that hasn't been answered in two days.
    <P>
    Really can't figure out what's wrong. I guess my next step is to start over again (though this is a clean, new install), adding one plugin at a time until I find a culprit (assuming taking all the plugins out makes it work) My mind is fried. Been working on this in 100+ degree heat for 6 days now, UGH!
    <P>
    Review, two problems:
    <P>
    1. To me it seems that permissions are not being read in the groups because when I put them directly under the player's name, it works
    2. Nobody, not even admin, can build or destroy. can do anything else, access commands if the permissions were put under player names, but can't build or destroy.
    <P>
    Does nobody else have this?
     
  27. Offline

    ZerothAngel

    It's written in the OP under "How do I use SuperpermsBridge?"

    Basically, if you want wildcards to work for any plugin that only uses the Permissions 2/3 interface, you have to prefix the permission with "superpermbridge."

    If the plugin is using SuperpermsBridge, then that's the issue -- SuperpermsBridge doesn't support groups at all.
     
  28. Offline

    Darcion

    i use setrankPB and it worked very easy now i can give my mods special rights for promote players into a new group and not himself into admin group.
     
  29. Offline

    Scandragon

    I can use superpermbridge to give permissions to groups just fine.
    Superpermsbridge doesn't need to support groups at all..
     
  30. Offline

    Deathlysteve-

    is SLB a player or Group...?
     
  31. Offline

    olimoli123

    SQL support ever?
     

Share This Page