[ADMN/DEV] PermissionsBukkit v2.0 - Official Default Groups Plugin [1.5.2-R1.0]

Discussion in 'Archived: Plugin Releases' started by SpaceManiac, Jul 17, 2011.

  1. Offline


    PermissionsBukkit - the Official Default Groups Plugin
    Current Version: v2.0
    Find PermissionsBukkit on BukkitDev!

    If you are getting a specific error or cannot determine what is wrong with your permissions file, filing a ticket on BukkitDev will make me much more likely to respond to you; general questions are best to ask in this thread or on the forums on BukkitDev.

    It's been a long time coming, but with the accomplishment of build 1000 Bukkit has finally accomplished a built-in Permissions system (codenamed Superperms). For more info on how they work, and how to integrate them with your plugin, see the official Permissions FAQ. Keep in mind that you should rarely, if ever, have to hook this plugin directly; instead keep things in the realm of checking player.hasPermission("yourplugin.node"). The FAQ thread has more info on how to use Superperms with things like chat prefixes/suffixes.

    • Storage of users and groups in plugins/PermissionsBukkit/config.yml.
    • Both users and groups can be assigned individual permissions and parent groups to inherit permissions from.
    • Support for global and per-world permissions.
    • Reload configuration from file with out reloading the plugin.
    • Ability to check if a player has a specific permission node.
    • Ability to dump all permissions a player has and the plugins that set them.
    • Ability to print plugin, description, and default for a given permission node.
    • Ability to modify the permissions of groups and users and the groups of a user in-game.
    • Built-in antibuild via the "permissions.build" node (defaults to allowing anyone to build).
    • A minimalistic bridge from Permissions 3.0 to Superperms is available as a separate plugin, which does not depend on PermissionsBukkit.
    Command Usage:

    Show Spoiler
    PermissionsBukkit uses the command /permissions, with aliases /perms and /perm.

    /permissions reload - reload the configuration from disk.
    /permissions check <node> [player] - check if a player or the sender has a permission (any plugin).
    /permissions info <node> - prints information on a specific permission.
    /permissions dump [player] [page] - prints info about a player's (or the sender's) permissions.
    /permissions setrank <player> <group> - set a player to be in a group with per-group permissions.
    /permissions group - list group-related commands.
    /permissions group list - list all groups.
    /permissions group players <group> - list players in a group.
    /permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group.
    /permissions group unsetperm <group> <[world:]node> - unset a permission on a group.
    /permissions player - list player-related commands.
    /permissions player groups <player> - list groups a player is in.
    /permissions player setgroup <player> <group,...> - set a player to be in only the given groups.
    /permissions player addgroup <player> <group> - add a player to a group.
    /permissions player removegroup <player> <group> - remove a player from a group.
    /permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player.
    /permissions player unsetperm <player> <[world:]node> - unset a permission on a player.

    All commands have in-game help and are usable from the server console.

    Show Spoiler
    A permission node is a string like 'permissions.build', usually starting with the name of the plugin. Refer to a plugin's documentation for what permissions it cares about. Each node should be followed by true to grant that permission or false to revoke it, as in 'permissions.build: true'. Some plugins provide permission nodes that map to a group of permissions - for example, PermissionsBukkit has 'permissions.*', which automatically grants permissions for all PermissionsBukkit commands. You can also specify false for permissions of this type.

    Users inherit permissions from the groups they are a part of. If a user is not specified here, or does not have a 'groups' node, they will be in the group 'default'. Permissions for individual users may also be specified by using a 'permissions' node with a list of permission nodes, which will override their group permissions. World permissions may be assigned to users with a 'worlds:' entry.

    Groups can be assigned to players and all their permissions will also be assigned to those players. Groups can also inherit permissions from other groups. Like user permissions, groups may override the permissions of their parent group(s). Unlike users, groups do NOT automatically inherit from default. World permissions may be assigned to groups with a 'worlds:' entry.

    The cannot-build message is configurable. If it is left blank, no message will be displayed to the player if PermissionsBukkit prevents them from building, digging, or interacting with a block. Use '&' characters to signify color codes.

    An example configuration file might look like this:
                permissions.example: true
            - admin
                permissions.build: false
                permissions.*: true
            - user
                permissions.build: true
                    coolplugin.item: true
            - default
        build: '&cYou do not have permission to build here.'

    Show Spoiler
    PermissionsBukkit checks for the following permission nodes:
    • permissions.build - Allows a player to build. Defaults to true.
    • permissions.help - Allows viewing of usage for /permissions.
    • permissions.reload - Allows use of /permissions reload.
    • permissions.check - Allows use of /permissions reload.
    • permissions.info - Allows use of /permissions reload.
    • permissions.dump - Allows use of /permissions reload.
    • permissions.group.help - Allows viewing of usage for /permissions group.
    • permissions.group.list - Allows use of /permissions group list.
    • permissions.group.players - Allows use of /permissions group players.
    • permissions.group.setperm - Allows use of /permissions group setperm.
    • permissions.group.unsetperm - Allows use of /permissions group unsetperm.
    • permissions.player.help - Allows viewing of usage for /permissions player
    • permissions.player.groups - Allows use of /permissions player groups.
    • permissions.player.setgroup - Allows use of /permissions player setgroup.
    • permissions.player.addgroup - Allows use of /permissions player addgroup.
    • permissions.player.removegroup - Allows use of /permissions player removegroup.
    • permissions.player.setperm - Allows use of /permissions player addgroup.
    • permissions.player.unsetperm - Allows use of /permissions player removegroup.
    Also, the following parent nodes are provided for convenience:

    • permissions.* - Maps to permissions.help, .reload, .check, .info, .dump, and to permissions.group.* and permissions.player.*. Defaults to op.
    • permissions.group.* - Maps to permissions.group.help, .list, .players, .setperm, and .unsetperm.
    • permissions.player.* - Maps to permissions.player.help, .groups, .setgroup, .addgroup, .removegroup, .setperm, and .unsetperm.

    Frequently Asked Questions:
    1. Where are my * nodes? (open)
    Bukkit's Superperms has no built-in concept of a global '*' node that automatically gives all permissions, which is intentional - a player can instead be given all permissions by being given 'op' status (that is, listed in ops.txt). Additionally, individual plugins define a parent node (which could be 'pluginname.*' or 'pluginname.all' or anything else) which maps to whatever subpermissions in that plugin the author desires.

    An example is PermissionsBukkit, which provides three such permissions: 'permissions.group.*' for all /permissions group commands, 'permissions.player.*' for all /permissions player commands, and'permissions.*' for all /permissions commands (including permissions.group.* and permissions.player.*).

    If you are using SuperpermsBridge, you can do something similar to '*' nodes for plugins which use Permissions 2.7/3.1 - see the next FAQ for more information.
    2. How do I use SuperpermsBridge? (open)
    SuperpermsBridge is kind of like FakePermissions for GroupManager or PermissionsBridge for PermissionsEx. Once it's installed, it pretends to be the Permissions plugin and converts any plugins that use Permissions 2.7 or Permissions 3.1 to use Superperms instead.

    You can have PermissionsBukkit without SuperpermsBridge or SuperpermsBridge without PermissionsBukkit if you like, but both of these are limited in functionality. If you install SuperpermsBridge without PermissionsBukkit you will not be able to make use of PermissionsBukkit's groups feature or admin commands, and if you install PermissionsBukkit without SuperpermsBridge, plugins that have not updated to use Superperms directly will not function.

    For plugins that use Permissions 2.7/3.1, you can use the special node 'superpermbridge.*' to give the equivalent of what used to be the '*' node for plugins that do not use Superperms directly. If you don't want to give the * node, you can also use the node 'superpermbridge.pluginname' to do the equivalent of what used to be the 'pluginname.*' node. Once again, these only apply to plugins that SuperpermsBridge handles and not to plugins using Superperms directly.
    3. How do I use the root permissions.yml? (open)
    The file 'permissions.yml' in the root of your server can be used to set up custom parent permissions. Parent permissions are a single node that, when given to a player or group, automatically give all their children node. Here's a simple example:
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
    Now, if you give a player the node 'server.basics', they automatically get all the nodes listed here. Children may also say 'false' instead of 'true', in which case giving the parent will remove the child instead of giving it.

    You can also specify a description if you like, which can be used by plugins to provide information on your node (such as PermissionsBukkit's /perm info command). If you want, you can also provide a default, which can be one of "true", "false", "op", or "notop". CraftBukkit will automatically assign everyone, no one (default), ops, or non-ops the children permissions based on the specified default. Without any plugin like PermissionsBukkit, you can use this defaults system as a limited way to assign people permissions. Here's a more complex example:
        description: Basic permissions for My Cool Server.
        default: true
            commandbook.motd: true
            commandbook.say: true
            commandbook.say.me: true
            commandbook.time: true
        description: Admin permissions for My Cool Server.
        default: op
            commandbook.broadcast: true
            commandbook.teleport: true
            commandbook.kick: true
            commandbook.ban: true
    You can also define permissions without children, but this is of limited usefulness in permissions.yml (though is important in plugin.yml; see question #6)
    4. How do I switch from (other Permissions plugin)? (open)
    Depends on the Permissions plugin! If you were using PEX's YAML backend, I have a converter done and available on the PermissionsBukkit Tools page. Also available on the tools page is an automatic converter for Essentials GroupManager users.yml and groups.yml files. Automatic converters for Permissions 2.7 and 3.x are on their way, but in the meantime you can still convert your configurations manually.
    5. Where are prefixes and suffixes (or option nodes)? (open)
    Bukkit Superperms has no built-in prefix/suffix settings or non-boolean permission nodes, so individual chat plugins will have to start supporting Superperms in order to make use of non-Permissions-plugin based prefixes and suffixes. Herochat, iChat, and Simple Suffix are all aware of the Superperms update, but in the meantime you can use mChat, which already supports Superperms.

    Once you install mChat and configure the mchat.prefix, mchat.suffix, and mchat.group names in its configuration file (see the example), use PermissionsBukkit to give players or groups the permissions "mchat.prefix.admin", replacing "admin" with whatever node you configured. For example, with an mchat configuration that looks similar to this:
    da-name-format: '+prefix+name&e'
    date-format: HH:mm:ss
    message-format: '+prefix+name&f: +message'
            admin: '&4DtK [SO] &7 '
            sadmin: '&9DtK [SA] &7 '
            jadmin: '&aDtK [JA] &7  '
            member: '&cDtK [M] &7 '
    You can assign players or groups the mchat.prefix.admin node to get the "SO" prefix, mchat.prefix.sadmin to get the "SA" prefix, and so on.
    6. (Coders) How do I set up my plugin.yml? (open)
    Take a look at this post in Dinnerbone's FAQ for an example. This is a lot like the setup of permissions.yml (see above), but you can also define non-parent permissions (just include description and default and leave out children).
    7. Is PermissionsBukkit outdated? (open)
    No! PermissionsBukkit 2.0 was last updated for 1.3.1-R2.0, is verified to work on 1.4.7-R1.0, and is unlikely to break on future releases.

    Current Version:

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



    Friday 7 September 2012 (2.0)
    • Fixed a case-sensitivity issue with setting per-world permissions that could cause some permissions to fail to apply.
    • Added /perm setrank <player> <group> subcommand (alias rank) with per-group permissions (permissions.setrank and permissions.setrank.<group>)
    • Added plugin metrics via http://mcstats.org/plugin/PermissionsBukkitMCStats (disableable in plugins/PluginMetrics/config.yml)
    Wednesday 29 February 2012 (1.6)
    • Fixed some massive issues that were caused due to having uploaded a buggy, in-development version instead of 1.5.
    • Note: If your configuration was messed up as a result of this issue, the new build should gradually correct it as needed.
    Saturday 25 February 2012 (1.5b)
    • Revamped to be compatible with R5.
    • Fixed issues with permissions not carrying properly on world change.
    • Many internal improvements for performance and stability.
    • SuperpermsBridge: in honor of R5 removing deprecated code, SuperpermsBridge is officially gone!
    Monday 18 July 2011 (1.1/1.2)
    • Fix BukkitContrib incompatibility issues.
    • Improved the output of the /perm check command.
    • Fixed issues when 'users:' is not specified in the config file.
    • Fixed the /permissions reload command.
    • SuperpermsBridge: improve wildcard handling; in addition to 'superpermbridge.*' and 'superpermbridge.pluginname', now supported are 'superpermbridge.plugin.*', 'superpermbridge.plugin.subnode.*', and so on.
    Monday 18 July 2011 (1.0/1.1)
    • SuperpermsBridge: adding the special 'superpermbridge.*' and 'superpermbridge.pluginname' nodes (see #2 in the FAQ for details).
    Sunday 17 July 2011 (1.0/1.0)

    • Initial release of PermissionsBukkit v1.0 and SuperpermsBridge v1.0.
    madmac, Gesundheit, tripleX and 23 others like this.
  2. Offline


    i have remove now the : true but its still not working.
  3. Offline


    Oh well, no big deal. Thanks anyways.

    I have my "permissions.*" under my parent permission "server.moderator" inside the new permissions.yml file. And it works when I put "server.moderator: true" under a group. Maybe if you did the same it should work.

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


    ok i found out it give no Always Permission in PermissionBukkit XD
    permissions.* are only for the premissions commands from PermissionBukkit ...
    now i most add all permissions for testing XD thats bad XD

    But why levelcraft permission dont work is still a problem xD

    ok now i have make it to work XD
    i have add now all plugins with plugin.* but after i make a /reload i dont have any premissions anymore and most restart the server.

    what is that? a bug?
  5. Offline


    Hey could you talk to PhonicUK about the Default groups? I'm having issues with my newly joined users ACTUALLY being in the group. I have to add their username into the "Everyone" group for the name/build rights to set in.

    Oh and anything with a * in it doesn't work. I have to manually add each command, which isn't too terrible, but still.
  6. Offline


    when i kick a player i get this in the log files

    22:24:06 [SEVERE] Could not pass event PLAYER_QUIT to PermissionsBukkit
    java.lang.IllegalArgumentException: Attachment cannot be null
            at org.bukkit.permissions.PermissibleBase.removeAttachment(PermissibleBase.java:134)
            at org.bukkitcontrib.player.ContribCraftPlayer.removeAttachment(ContribCraftPlayer.java:140)
            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:332)
            at net.minecraft.server.ServerConfigurationManager.disconnect(ServerConfigurationManager.java:146)
            at net.minecraft.server.NetServerHandler.disconnect(NetServerHandler.java:117)
            at org.bukkit.craftbukkit.entity.CraftPlayer.kickPlayer(CraftPlayer.java:135)
            at com.sk89q.commandbook.commands.ModerationCommands.kick(ModerationCommands.java:140)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:597)
            at com.sk89q.minecraft.util.commands.CommandsManager.executeMethod(CommandsManager.java:343)
            at com.sk89q.minecraft.util.commands.CommandsManager.execute(CommandsManager.java:256)
            at com.sk89q.commandbook.CommandBookPlugin.onCommand(CommandBookPlugin.java:245)
            at org.bukkit.command.PluginCommand.execute(PluginCommand.java:35)
            at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:129)
            at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:320)
            at net.minecraft.server.NetServerHandler.handleCommand(NetServerHandler.java:713)
            at net.minecraft.server.NetServerHandler.chat(NetServerHandler.java:677)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:670)
            at net.minecraft.server.Packet3Chat.a(Packet3Chat.java:33)
            at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:85)
            at net.minecraft.server.NetworkListenThread.a(SourceFile:105)
            at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:451)
            at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:361)
            at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
  7. Offline


    Any easy way to use old style permissions until this gets more streamlined. I don't care for the way it is and don't quite understand the point of the permissions.yml file in the root. It seems as though I can create groups in there but whats the point when I can already create groups?

            - admin
            - admin
            - Weavers
                permissions.build: true
                permissions.*: true
                server.basics: true
                server.admin: true
            - user
                permissions.build: true
                    coolplugin.item: true
            - default
               server.basics: true
            - Default
               server.basics: true
            - Default
               server.basics: true
            - Default
                server.basics: true
            - Default
                server.basics: true
            - Default
        build: '&cYou do not have permission to build here.'
    CraftBookCommon: No known permissions plugin detected. Using configuration file for permissions. Basically the only way anything works is if I OP myself. All the other players cant use things like /list /who /msg. Someone please tell me this plugin is just broken or something.

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


    it is a veri good plugin
    Thank !
    but i haven't got a friend who can help me
    i went if someone have the time a another example of "config.ylm"
    (i life with the examples...)

    sorry for my bad english
    i'am a french who you like :)

  9. Offline


    @TheMap The permissions.yml isn't really used for makeing groups, but rather parent permission nodes. For example, you could set only the permission nodes you want for normal normal players under the parent permission 'server.normal'. Then you could do the same for admins, but excluding the permissions you already set for 'sever.normal'. That way you can just have server.normal under the normal group and server.normal and server.admin under the admin admin group. The normal group would have only what is under server.normal and the admin group will get what the normal group has plus whatever is set under sever.admin. it might not seem like a big deal but it really helps with organization and not having to put the same permission node for every group just for one plugin. It gives your files more uniform.
  10. Offline


    I understand that now, but that still doesn't explain why this doesn't seem to work. I have never had an issue with any permissions done, even when groupmanager came out I picked it right up and ran with it. But for some reason permissions doesn't seem to do anything for me. Sure I can op myself and a friend if I want to edit a map. But forget bringing in any groups as they don't seem to do anything.
  11. Offline


    It basically doesnt work at all.
    I set exporting as mchat+permissionsbukkit thats fine.
    yes it exports.
    but when i change something like make admins have *
    it dont work in the actual game! but it says "superpermsbridge.*" or something in the config!!
    i also set another group to have certain stuff, doesnt work but shows up in the config
    like nothing at all works with it!!! urghh!!!
    Servercraft is hosting my server and they refreshed the whole permissions, started it from scratch and it still didnt work!!!! :mad:
  12. Offline


    Good... evening, morning, whatever.

    As I got fed up by giving everyone who wants to build operator rights, I thought about using a permissions plugin. But soon I noticed by browsing the forums, Bukkit already has one implemented. I cheered because I thought it would be easier for me to set everything up, but it seems I had cheered too early. Now that FAQ tells me to download this plugin here, fine, I said, so it shall be. Done that.
    You might call me a bad server owner or even a noob, but here is my problem:
    I have no idea about how to set this up. I don't know what to put into the config file, how to configure groups, how to add users to these groups without inserting them manually by opening the file (I don't even know whether there's a command or not), what to add into whatever.
    You see; I'm confused.

    Allow me to explain what I wanted to do.
    I've got one world and the Nether, dunno if that matters.
    Now I have got the following plugins :

    I want to have several groups with different permissions.
    There's me, the owner. I, of course, want to have all powers available, shouldn't be that hard.
    Then the ordinary operators being able to kick, change weather, build, use WorldEdit and WorldGuard and OpenInv to check for, let's say, TNT and all other stuff that an operator is able to do on default, except banning.
    Then there's my clan which should be able to use WorldEdit, the /give-command and /time-command and of course build.
    Then there's the average builder, being able to use /give and /time. It also should be the default group for newly joined.
    And last but not least a group for imprisoned. They are allowed to walk, but that's it.

    I know this is already a huge post, but now to my matter of concern.
    1. Would anyone please make me a config file for what I listed above? I would thank him forever.
    2. You know my plugins, can you recommend me some more which might come in handy? Only optional, though I'd still very much appreciate it.

    Excuse grammar stuff, it's late at night/early in the morning.
    Thanks in advance.
  13. Offline


    @SpaceManiac, perhaps I'm just a picky bastard but you might want to check the Permissions section.
    I gather they don't all do the same thing and infact give the user permissions to the command of the same name as the node.

    Should have been this?
    • permissions.reload - Allows use of /permissions reload.
    • permissions.check - Allows use of /permissions check.
    • permissions.info - Allows use of /permissions info.
    • permissions.dump - Allows use of /permissions dump.
  14. Offline


    If anything, this is comforting to me, because I now know I'm not a total idiot and other people are having problems. My permissions for McMyAdmin are kinda spotty, promotions WERE working but then decided to stop, I'm finding that using *'s for all commands isn't working, build rights are kinda shot, default group is failing to load (more on that in a bit), and some permissions just aren't working at all.

    As for default groups, as I know I'm not doing anything wrong, I will write it out. Titles (prefixes, colors, suffixes, etc) don't work for default group, nor do build rights. I'm finding that I have to manually add users into the default group for the title/no building to take effect.

    I wouldn't QUITE call it streamlined.
  15. Offline


    yehh soo irritating! :mad:
    ive just reverted back to Permissions 3.x untill someone helps me/us out.
    permissions 3.x works fine with McMyAdmin, but with iChat the colours dont seem to work btu watever that dont matter
    someone, show me wtf is wrong with what ive done.
  16. Offline


    Can you PLEASE add support for xAuth! My server needs this, And I use McMyAdmin and This is the only good Group manager. Please Help. Sorry I cant get info to the error.
  17. Offline


    My server says there is no permissions plugin detected. What's wrong?
  18. It means your plugins are still trying to read the old permissions format. You need PermissionsBridge to translate the new permissions to the old ones.
  19. Offline


    Yeah, this happen by:

    ->Kick player
    ->death>title menu>relogg
    ->when some try to join the game and he is not on the Whitelist

    Whith this bug we can't start/ open the server. :s
  20. Offline


    by the way i like the new permission system, first it was a bit confusing but after some reading i understand how to set up :)
  21. Offline


    I've encountered an interesting problem with the bridge and WorldGuard in that it can not seem to find any groups. This is the only plugin I use that specifically looks for groups for what it does (blacklist, region protection etc). I've posted a longer explanation on their forums. The upshot of it is that I have had to start using Permissions 3.1.6 again because of this bug.

    My question is does the bridge return the group players are in yet?
  22. Offline


    inheritance of permission.yml nodes doesn't work for me
    in the config below member hast default permissions,
    but mod have just member permission and not the default permission.
    admin hast the permission of a mod but not the member and default

        description: Guest permissions
            commandbook.motd: true
            commandbook.rules: true
            commandbook.spawn: true
        description: Member permissions
            mchat.me: true
            commandbook.who: true
            commandbook.time.check: true
            commandbook.return: true
            commandbook.say: true
            commandbook.msg: true
            commandbook.mute: true
            commandbook.clear: true
            commandbook.whois: true
            commandbook.whois.other: true
            commandbook.call: true
        description: Mod permissions
            commandbook.teleport: true
            commandbook.teleport.other: true
            commandbook.broadcast: true
            commandbook.kick: true
            commandbook.bans.ban: true
            commandbook.bans.unban: true
            commandbook.bans.isbanned: true
        description: Admin permissions
            mchat.reload: true
            commandbook.time: true
            commandbook.give: true
            commandbook.give.other: true
            commandbook.give.infinite: true
            commandbook.give.stacks: true
            commandbook.give.stacks.unlimited: true
            commandbook.more: true
            commandbook.more.infinite: true
            commandbook.setspawn: true
            commandbook.spawnmob: true
            commandbook.clear.other: true
            commandbook.bans.load: true
            commandbook.bans.save: true
            commandbook.reload: true
            commandbook.weather: true
            commandbook.weather.thunder: true
            commandbook.slap: true
            commandbook.slap.other: true
            commandbook.rocket: true
            commandbook.rocket.other: true
            commandbook.shock: true
            commandbook.shock.other: true
            commandbook.thor: true
            commandbook.thor.other: true
            SimpleGodMode.isGod: true
        description: Owner permissions
            commandbook.time.lock: true
            commandbook.spawnmob.many: true
            SimpleGodMode.isGodByDefault: true
                permissions.build: false
                server.default: true
                permissions.build: true
                server.member: true
            - default
                permissions.build: true
                server.mod: true
            - user
                permissions.*: true
                server.admin: true
            - mod
                permissions.*: true
                server.owner: true
            - admin
  23. Offline


    I cant seem to get default groups to work, and craftbook, its giving building errors, and the permission that fixes that is in the default group....! maybe that's not inheriting "craftbook.mech.*", and people in the default group can't use commands, because that group only works, and they get commands, if they get manually added to the file...

    I think others are having the same issue...
  24. Offline


    That's because there is no "*" permission in PermissionsBukkit you muppet. Read the thread for it! McMyAdmin puts in a superpermsbridge.* to help with backwards compatbility with older plugins. You can't have *: true as a permissions node.
    arthoz likes this.
  25. Offline


    Erm, im sorry if im being too noobish
    how could i add a permission thro a code, to a player ?
    ex. player.addPermission(player, "my.permission")

    Is it possible ?

    thanx for any help.
  26. Offline


    any eta on when we might see mysql support?
  27. Code:
    HashMap<Player, PermissionAttachment> permissions;
    // ..
    if (player.hasPermission("can.we.fix.it"))
        if (player.hasPermission("currently.fixing"))
            player.sendMessage("You are no longer fixing it.");
            permissions.put(player, player.addAttachment(plugin, "currently.fixing", true));
            player.sendMessage("You are now fixing it.");
    Is this satisfactory?
    Ziden likes this.
  28. Hmm, I still don't understand why the new bukkit has permissions.yml in the root folder. Ah well, this plugins works like a charm.
  29. Offline


    I'm still waiting for the default group to load properly...
    Servercraft support said it was a quirk with the plugin. If that bug could be fixed, it would be nice.
    I'm also now getting a message saying "You don't have permission to do this" when anyone other than an op tries to place a block. WorldGuard I guess... But I need WorldGuard.

    I'm going back to EssentialsGroupManager. Forget this. I can't run a plugin that stops 50% of the important functions on my server.
    Deathlysteve- likes this.
  30. This plugin doesn't stop 50% of the important functions. The plugins just aren't set up to handle it yet because most of the developers haven't adapted yet.

    It's the plugin developers, not Superperms that are at fault. But there's nothing stopping you from using your original permission system just like before.
  31. Offline


    I can't get people to be added to the default group automatically. Here my code,

                essentials.mail.send: true
                essentials.mail: true
                essentials.msg: true
                essentials.spawn: true
                essentials.suicide: true
                factions.create: true
                factions.participate: true
                falsebook.*: true
                turnstile.open: true
                essentials.list: true
                essentials.motd: true
                movecraft.*: true
                mchat.prefix.Citizen: true
                mchat.suffix.Citizen: true
                permissions.build: true
            - default
    I have both bukkitpermissions and superperms added. I don't have any old permission .jars or anything. What should I do to make this work?

Share This Page