[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

    Slyvr89

    I'm a bit of a noob with permissions, so anyone can probably help me with this question. Do you have to add permissions to all plugins or just the ones you want to set to true?

    For example: THIS
    Code:
    permissions.build: true
    cbr.place.[torch]: true
    magicspells.learn.forcepush: true
    magicspells.cast.forcepush: false
    worldedit.*: false
    OR THIS
    Code:
    permissions.build: true
     cbr.place.[torch]: true
     magicspells.learn.forcepush: true
    Or perhaps the default group should have everything set to false and then user and admin inherit from it and override certain permissions set to true
     
  3. Offline

    khamseen_air

    You only need to list the permission nodes you want users to have.
     
  4. Offline

    monir

    Please make a youtube movie so it will be easier to understand
     
  5. Offline

    Fretfulregrets

    Man I wish more plugins would support this.
     
  6. Offline

    Slyvr89

    Thank you khamseen,

    I have another question. Is there a way to do permissions.build: false except for a couple blocks...such as chests and torches. I want the default to be able to open chests but not destroy them and place but not destroy torches
     
  7. Offline

    khamseen_air

    Not through permissions I'm afraid. There may be a plugin, something like worldedit that may do it. Not overly sure though as I've never had use of restrictions like that myself.
     
  8. Offline

    Slyvr89

    Ah, thanks again. I'm using a plugin Custom Block Restriction, but just wondering if I could do it more easily through permissions without having to list every single block
     
    khamseen_air likes this.
  9. Offline

    Pand3micc

    The old permissions 2.x had a really good antibuild, chests and other interact-able blocks were still useable.

    Also does anyone know why I can't have per-world build permissions?
     
  10. Offline

    joselitoeu

    Please?
     
  11. Offline

    Retricide

    Would anyone be interested in developing, or integrating into permissionsbukkit, a promotion plugin (with ladders, etc)?
    Im really looking for a plugin to handle promotions before I switch from PEX to superperms.
     
  12. Offline

    Flaminglynx

    Yeah i gave up, but now it seems like I need to find a different permissions plugin again. the permissionbukkit.jar dosent seem to work at all. the server wont load it. any recommendations for what permissions plugin i could use that works?

    I switched to the dev .jar and it worked somehow. the permissionsbukkit.jar didn't work it wouldent even load in the terminal. idk why it wouldent work.

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

    1born2kill

    Dont we already have something similar to this in the plugin?

    I've worked with this for almost 8hrs straight now lol and i think i got this plugin...

    but yeah u can do /permissions player setgroup <name> <rank>

    its like /promote, but longer haha, it gets wicked easy if u have Spout :D
     
  14. Offline

    Retricide

    But, is there a check or rank? With this I imagine anyone will be able to set any rank. Using the track promotion system, people will not be able to promote past, or to, their rank, and the system will also simplify the command to promote(usually).
     
  15. Offline

    1born2kill

    I dont really get what u saying, but:

    I only allowed myself and other HIGHLY trusted members to do this. Only people with this permission can do the ranking ups, everyone else who are players have to fulfill the task before they can "rank" up... there isnt a plugin that automatically ranks up people by doing task... BUT ik a plugin that ranks people up through playing, and its called
    "Time Rank"
     
  16. Offline

    Retricide

    Thats interesting, I'll take a look at it.
    Regardless though, this type of promotion system had been implemented in all past, major permission plugins (Groupmanager, Permissions, PEX), and definitely needs to be added to permissions bukkit.
     
  17. Offline

    Drakia

    @SpaceManiac Really, this is the "default Permissions plugin" and you have a GIANT bug like this? I just spent twenty minutes trying to figure out why the hell my account had no Permissions assigned to it.

    And look at that, this happens if I disconnect after a reload:
    Code:
    22:06:21 [SEVERE] Could not pass event PLAYER_QUIT to PermissionsBukkit
    java.lang.IllegalArgumentException: Given attachment is not part of Permissible
    object org.bukkit.permissions.PermissibleBase@1d74f478
            at org.bukkit.permissions.PermissibleBase.removeAttachment(PermissibleBase.java:147)
            at org.getspout.spout.player.SpoutCraftPlayer.removeAttachment(SpoutCraftPlayer.java:138)
            at com.platymuus.bukkit.permissions.PermissionsPlugin.unregisterPlayer(PermissionsPlugin.java:137)
            at com.platymuus.bukkit.permissions.PlayerListener.onPlayerQuit(PlayerListener.java:24)
            at org.bukkit.plugin.java.JavaPluginLoader$2.execute(JavaPluginLoader.java:251)
            at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:58)
            at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:338)
            at net.minecraft.server.ServerConfigurationManager.disconnect(ServerConfigurationManager.java:146)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:628)
            at net.minecraft.server.NetworkManager.b(NetworkManager.java:231)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:89)
            at org.getspout.spout.SpoutNetServerHandler.a(SpoutNetServerHandler.java:436)
            at net.minecraft.server.NetworkListenThread.a(SourceFile:105)
            at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:454)
            at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:363)
            at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
     
  18. Offline

    krinsdeath

    @Drakia - This already exists, but I've confirmed it and it is ~definitely~ in my version. I've been fixing bugs, and Space is gone right now so he can't really respond.
    Code:
    @Override
    public void onEnable() {
      ...
      for (Player p : getServer().getOnlinePlayers()) {
        registerPlayer(p.getName());
      }
      ...
    }
    
    http://files.krinsoft.net/main/java/PermissionsBukkit-1.2.jar
    https://github.com/krinsdeath/PermissionsBukkit
    @Retricide - When I get some time, I'll look into creating a ladder system for this, but right now it's not a huge priority.

    I do not recommend using the "promoted" version of this jar (version 1.1). There are numerous glaring bugs that have since been fixed (in the dev versions, and my own release). Since I'm not the original creator of the topic, I can't promote these builds. :[
     
  19. Offline

    Drakia

    So the current "official" release is buggy as shit, the dev is gone, and we're left with third-party builds. Woo, nice system the Bukkit team has going here...
     
  20. Offline

    krinsdeath

    @Drakia - Aren't you a developer? A link to the current release's source is in the main post. The issue you just posted is not even present in the latest promoted build. Stop finding reasons to complain.

    Furthermore, I don't believe any of the official bukkit staff has anything to do with this project. It was simply developed in tandem with Permissions as they were being implemented. While I feel that this plugin is superior to both PermissionsEx and bPermissions (the alternative Superperm group managers), nothing is stopping you from using them!

    And though I'm not responsible for the initial releases, I contributed to a number of subsequent bugfixes, and as such I feel like "third party" doesn't rightly describe my continuing contributions to the project. I'll gladly address any problems you may be having, because I have been for the entire duration of the project's release.

    I guess what I'm trying to say is... don't get your panties in a bunch. Bugs happen.
     
  21. Offline

    Drakia

    @krinsdeath Yes, I'm a dev, and I actually had the wipe (Or maybe it wasn't loading perms in the first place?) bug with the latest dev release before I downloaded your copy. Also I'll find as many reasons to complain as I want, I hated SuperPerms to begin with, this plugin just makes it even funnier ;)
    From the plugin topic title: "PermissionsBukkit v1.1 - Official Default Groups Plugin" From the first post: "PermissionsBukkit - the Official Default Groups Plugin" -- If it's not official, that should probably be removed :)

    As for you being a "third-party" I see your name listed nowhere in the first post, so to me and many other people who see you posting builds, you are a third-party. Good job for supporting the plugin though. Great plugin, besides the massive bugs in the current "official" release ;)
     
  22. Offline

    RustyDagger

    @Drakia

    well well well if it ain't ""MR super perms are crap"" him self. using super perms this is a wonderful day. Super perms are great aint they drakia being able to make new permission nodes as a server owner is very nice. commands are simple and all.

    on another note i don't see what i posted as a huge problem just slightly annoying it in no way effects how the plugin works under normal server usage. its rare i would reload my live server while any 1 bar my self is in it because i do 99% of testing and config work locally and any experienced server admin would do the same.

    Another thing there is nothing wrong with team work i would sooner see @krinsdeath help out with this plugin than to go off and make yet another manager. just because of a small issue. So no theirs nothing wrong IMO with him posting a fix for a problem. no doubt he will request a pull and it will be implemented officially when the dev returns.
     
  23. Offline

    Drakia

    @RustyDagger I still hate SuperPerms, don't get me wrong, but if it's being used I'll add support for it ;) My server however is still on Permissions 2.7 :p
    As for nodes, they are only as simple as plugin devs make them, or as complicated as plugin devs make them, it has nothing to do with SuperPerms.

    The main problem is I have very little coding time, I spent a large portion of it trying to figure out why in the hell my permissions were wiped, continually reloading, using "/permissions reload", etc. It hadn't even crossed my mind to disconnect and reconnect, because that's just stupid.

    I never said there was anything wrong with teamwork, just that he is technically a third party, he's not mentioned in the first post anywhere. Why would I say good job otherwise?
     
  24. Offline

    rabiebear

    i cant get this or any other plugin to work right i edited the configuration so i can make new groups and it just wont work no matter what iis there any way you can help me. Also i cant get a prefix like [Owner] rebiebear :blah blah blah. here is the config tell me if any errors please.
    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:
        rabiebear:
            permissions:
                permissions.*: true
            groups:
            - owner
    groups:
        default:
            permissions:
                permissions.build: true
                essentials.help: true
                essentials.spawn: true
                essentials.tpa: true
                essentals.balance: true
                essentials.sethome: true
                essentials.home: true
                essentials.pay: true
                essentials.nick: true
                essentials.rules: true
                essentials.msg: true
                essentials.mtod: true
                essentials.list: true
                essentials.helpop: true
                essentials.spawn: true
                essentials.whois: true
                showcase.basic: true
                signlift: true
            world:
            - world
    
        owner:
            permissions:
                permissions.*: true
                essentials.*: true
                worldedit.*: true
                worldguard.*: true
                simplejail.*: true
                bigbrother.*: true
                craftbook.*: true
                craftbookcircuts.*: true
                craftboolmechanisims.*: true
                regios.*: true
                showcase.*: true
                citizens.*: true
                simplejail.*: true
                stickii.*: true
                herochat.*: true
                *: true
            worlds:
             - world
            inheritance:
            - co-owner
        builder:
            permissions:
                permissions.build: true
                magiccarpet.mc: true
                essentials.kick: true
                essentials.time: true
                essentials.weather: true
            worlds:
            - world
            inheritance:
            - default
    
        moderator:
            permissions:
                permissions.build: true
                essentials.give: true
                essentials.god: true
                essentials.kick: true
                worldedit.wand: true
                worldguard.region: true
                worldedit.expand.vert: true
                essentials.heal: true
                essentials.teleport: true
                simplejail.togglejail: true
                essentials.compass: true
                essentials.nick: true
                essentials.realname: true
                essentials.mail.send: true
                essentials.mail: true
                essentials.kit.tools: true
                essentiaals.getpos: true
                essentials.depth: true
                essentials.jump: true
            worlds:
            - world
            inheritance:
            - builder
    
        admin:
            permissions:
                permissions.build: true
                worldedit.set: true
                worldedit.undo: true
                worldedit.redo: true
                worldedit.replace: true
                worldedit.walls: true
                essentials.tempban: true
                essentials.setwarp: true
                essentials.delwarp: true
             worlds:
             - world
            inheritance:
            - moderator
    
        c.e.o:
            permissions:
                permissions.build: true
                essentials.thru: true
                bigbrother.bb.log: true
                bigbrother.bb.done: true
                showcase.infinate:true
             worlds:
             - world
            inheritance:
            - admin
    
        co-owner:
            permissions:
                permissions.build: true
                bigbrother.*: true
             worlds:
             - world
            inheritance:
            - c.e.o
    
        respected:
            permissions:
                permissions.build: true
             worlds:
             - world
            inheritance:
            - admin
    messages:
        build: '&cYou do not have permission to build here.'
     
     
  25. Offline

    monir

    please make a youtube movie how to install and use i think its hard to understand
     
  26. Offline

    Syntaxlb

    I have this for multi world :
    Code:
    groups:
        default:
            worlds:
                world1:
                    essentials.ping: false
                world2:
                    essentials.ping: true

    But /ping works on worldof AND world2... why ?

    EDIT: I don't know how to multi world work on this permission plugin :s

    I use MultiVerse

    EDIT2:
    I need to disconnect/reconnect to the server for permission take effect :s
    Example:
    I'm on world1 => /ping doesn't work, ok it's good
    I write : /mvtp world2 ; for be tp on world2
    I'm on world2 => /ping doesn't work, .... hmm not good !
    I disconnect/reconnect
    I'm on world2 => /ping work ! Good !
     
  27. Offline

    R4Z0R49

    WoW alot of hate going on in here. Anyway good job guys keep it up
     
  28. Offline

    mattdh

    I host a MineCraft server at MultiPlay, I have a selction of plugins - all of them are listed in my failing config. My config seems to always cause 'You do not have permission' errors whenever I try this.. I don't know what is wrong:
    Code:
    users:
        mattdholloway:
            permissions:
    
            groups:
            - admin
        mariopwnyou:
            permissions:
    
            groups:
            - admin
        Fluffy55:
            permissions:
    
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: false
        admin:
            permissions:
                permissions.*: true
                towny.admin: true
                iconomy.*: true
                mcmmo.*: true
                worldedit.*: true
                commandbook.*: true
                modtrs.*: true
                superpermbridge.*: true
            inheritance:
            - trusted
        member:
            permissions:
                permissions.build: true
            inheritance:
            - default
        trusted:
            permissions:
                permissions.build: true
            inheritance:
            - member
    messages:
        build: '&cYou do not have permission to build here. Please ask an admin for a rank up. :)'
    
     
  29. Offline

    nanashiRei

    To much caching. The 'worlds:' permissions don't update when players change the world. For example if one player has commandbook.give in one world and doesn't have it in the other he will still have it when he spawned in the world with it and then teleports to the other.

    This is a major issue and will lead to abuse of rights.

    Please fix asap. Thanks.
     
    Syntaxlb likes this.
  30. Offline

    Syntaxlb

    +1, Please fix this ! Thanks :)
     
  31. Offline

    Greu

    Hi and thanks for this simple and (almost... see below) ligthweight permissions plugins. I really like the simplicity and the logic of this plugin. However i have three things to say :

    Bug :
    Some plugins deal with the PlayerLogin event : a good exemple is http://forums.bukkit.org/threads/admin-vip-v0-4-2-gives-vips-priority-when-logging-in-1000.18822/. However, BukkitPermissions calculate the permissions list for a player only on the PlayerJoin event (which is called after the PlayerLogin event). So actually there is no way to check the permissions of a player during the PlayerLogin event :/ A simple fix is to call your "registerPlayer(Player player)" method on a PlayerLogin event with a high priority.

    Improvement :
    Another thing i noticed in your last dev version is the PlayerMove event. I don't want to be a jerk but calling the "setLastWorld" method (which call a least 2 or 3 "get" method on a HashMap object) on EACH PlayerMove event is a little ugly and cpu intensive ! I guess there is a cleaner way to check when the world of a player change.

    Request :
    Do you plan to create an API to your plugin ? To be able to change the group of a user, or add a permission from another plugin ?
     

Share This Page