[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

    Techykid3

    With Superpermsbridge, am I able to trust it and put it live? Because I really like the new permissions format, but I need to keep everything working.

    Another question, for mchat, On my test server I was setting that up, so for guest, I would give them:

    mchat.prefix.Guest: true
    mchat.group.Guest: true
    mchat.suffix.Guest: true

    But since Member would inherit from Guest, they would get the Guest Prefix, Suffix, and Group.

    So what I did was I gave this to the members:

    mchat.prefix.Member: true
    mchat.group.Member: true
    mchat.suffix.Member: true
    mchat.prefix.Guest: false
    mchat.group.Guest: false
    mchat.suffix.Guest: false


    And then the moderators would just do this (they inherit from Member), since in the Members group "guest" was already canceled out:

    mchat.prefix.Moderator: true
    mchat.group.Moderator: true
    mchat.suffix.Moderator: true
    mchat.prefix.Member: false
    mchat.group.Member: false
    mchat.suffix.Member: false


    Therefore, if I DIDN'T do that, and just gave each group their configuration, and didn't cancel out the previous group, It would for some reason inherit their mchat nodes, and so moderators would end up like this: [Member], when it should actually be [Moderator]...


    Am I doing too much to do this? Or is there an easier way? I have absolutely no problem, doing it this way, I'm just wondering if I was missing something that could make it a little easier.
     
  3. Offline

    Marsman75

    Hi,

    After I done some reading about the new bukkit release (#1000) I thought why not try and setup a own server. But after some more reading I found out that there is one thing I cant seem to find a good answer to so I post this post.

    After a install and simple run of the server you get some basic settings to the config.yml. There seem to be Three groups added

    default:
    admin:
    user:

    My question is this, do I haveto use these group names?

    Can I change these group names to something I rather want, for example default to Logger, Admin to OP, user to Member or something else in my own language. I mean does the admin commands, rights etc. work even if the group names are whatever they might be?

    And does a person get into the Logger group by default (not added to server in any way) when they login if I change the name of group from Default to logger?

    Thanks for grate work all

    Marsman
     
  4. Offline

    obscurehero

    THIS should be public knowledge or at least easily accessible. You've encapsulated what I think everyone ought to know about the new permissions system. There is still a lot of ambiguity and a lot of confusion, at least where I stand, about this switch.

    For a lot of server admins, this is a terribly confusing subject. If you don't mind, I'm going to re-post this more accessibly in the Bukkit Discussion section of the forums.

    Thanks!
     
  5. Offline

    emocookie1312

    can you help me whenever im admin or anything i do i set it so everyone can build but im able to destroy but not place blocks can anyone help
     
  6. Offline

    krinsdeath

    You could easily define aliases for all of that in your permissions.yml:
    Code:
    mchatAdmin:
        description: mChat admin prefix/group/suffix nodes
        children:
            mchat.prefix.admin: true
            mchat.group.admin: true
            mchat.suffix.admin: true
            mchatMember: false
    mchatMember:
        description: mChat member nodes
        children:
            mchat.prefix.member: true
            mchat.group.member: true
            mchat.suffix.member: true
            mchatDefault: false
    mchatDefault:
        description: mChat default nodes
        children:
            mchat.prefix.default: true
            mchat.group.default: true
            mchat.suffix.default: true
    
    And so on. Then just set "mchatMember: true" in your config.yml (in PermissionsBukkit), and it'll automatically disable all of the nodes associated with mchatDefault. The same rides true for your admins. You can do this for a potentially unlimited number of groups.
    The only immutable group is 'default'. All of the rest can be renamed at your leisure, but default needs to remain the same. Considering the group names mean nothing with this system (they're just ways of resolving permission nodes), it shouldn't be a problem. If, for example, you're using mChat, you can set up your chat prefixes and suffixes to have whatever group name(s) you want, and then give the appropriate nodes to the appropriate 'groups' in your config.yml.

    We need more information. Can you put a paste of your config.yml on pastebin?
     
    Marsman75 likes this.
  7. Offline

    emocookie1312

    # 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:
    ConspiracyWizard:
    permissions:
    permissions.example: true
    groups:
    - admin
    emocookie1312:
    permissions:
    permissions.build: true
    groups:
    - admin
    groups:
    default:
    permissions:
    permissions.build: true
    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.'
    this is my config
     
  8. Offline

    lemonzap

    is there a multiworld setting? I know group manager had separate config files for every world. this was necessary for my server so this would be great setting.
     
  9. Offline

    Marsman75


    Thank you for this suggestion, did not know that there was such a plugin, mChat, it is hard to keep track of them all ;)
    I understand now how to sort my problem. Did not find any good post with the info. and the search function in the forum seem not to work :oops:

    Thanks again

    /Marsman75
     
  10. Offline

    Teh Kitteh

    Alright so can someone please help me. Here is my configuration:

    Code:
    users:
        dasani233:
            permissions:
            groups:
            - admin
    groups:
        default:
            permissions:
                permissions.build: true
                commandbook.who: true
                commandbook.motd: true
                commandbook.time.check: true
                commandbook.time: true
                commandbook.spawn: true
                commandbook.say.me: true
                commandbook.setspawn: true
                commandbook.msg: true
                commandbook.whereami: true
                commandbook.ping: true
                commandbook.isbanned: true
                OwnBlocks.use: true
                OwnBlocks.info: true
                bb.blocks.allow.nportal: true
                bb.blocks.allow.fas: true
        admin:
            permissions:
                permissions.*: true
                commandbook.kick: true
                commandbook.bans.ban: true
                commandbook.bans.unban: true
                commandbook.mute: true
                OwnBlocks.ignoreOwnership: true
                bb.blocks.allow.*: true
                chestlock.admin: true
            inheritance:
            - user
        user:
            permissions:
                commandbook.broadcast: true
                commandbook.say: true
                bb.blocks.allow.lavabukkit: true
                chestlock.own: true
                chestlock.lock: true
                chestlock.unlockable: true
                chestlock.usekey: true
                chestlock.free: true
            inheritance:
            - default
    messages:
        build: '&cYou do not have permission to build here.'
    
    For some reason default users cant use /spawn, or /setspawn, and admins cant kick/ban/unban.
     
  11. Offline

    krinsdeath

    Make sure you have SuperpermsBridge.jar (latest version), and let me know if it still happens.
     
  12. Offline

    Varsis

    So... I don't know if this bug is reproducible for others, but it seems very consistent for me: Permissionsbukkit appears to be working correctly from the time a user logs in until they use a Multiverse 1.7.2 portal. From that point on, it continues to incorrectly use the permissions from the world they logged in on. I'm running RB 1000, permbukkit 1.1, bridge 1.2, and some other plugins like BB/LWC/MultiInv.

    If they reconnect, their permissions are once again correct until they take another portal. This is kind of a problem.
     
  13. Offline

    krinsdeath

    This is an issue that SpaceManiac is currently working on. I'm sure he'll let everyone know when it's done.
     
  14. Offline

    Teh Kitteh

    Thanks that fixed it. :D
     
  15. Offline

    SmartyGeek

    I keep getting this error! Can anyone help me?
    CB Build = 1000
    SuperPerm Version = 1.1
    Plugins = I will make a list later

    Do you need anything else?

    Code:
    >22:24:07 [SEVERE] Could not load 'plugins/PermissionsBukkit-1.1.jar' in folder 'plugins':
    
    while scanning for the next token
    
    found character'\t' that cannot start any token
    
     in "<reader>", line 161, column 1:
     
  16. Offline

    krinsdeath

    Your configuration has tab characters in it. You need to rewrite it with proper indentation using only spaces, not tabs.

    Ideally, you should do this with Notepad++ or some other editor that doesn't strip special characters (like notepad). Furthermore, please update to SuperpermsBridge 1.2 (in the first post).
     
    SmartyGeek likes this.
  17. Offline

    xezesis

    Have an odd problem I have set superpermbridge.logblock.*: true and logblock.*: true (future proofing) however it won't give me permissions. I have even checked ingame and it states superpermbridge.logblock.* is set to true
    I am running PermissionsBukkit 1.1 and SuperPermsBridge 1.2 oh and Loblock 1.2.3 which is stated as 1000 compatible (Without superperms, go fig?)
    Issue seems to have resolved itself for no apparent reason

    Arghh, sorry wrong topic didnt mean to click post

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

    The_Mole666

    Does it Work with other Plugins like Essentials?
     
  19. Offline

    4am

    If you install SuperpermBridge.jar, it creates an interface from the Bukkit Superperms into what looks like the old Permissions system to plugins, so that if they're not converted over to use Superperms yet, Superperms can still control them.

    It will therefore work with almost* all plugins right now. When they update to Superperms their nodes might change a bit (but they don't have to), but that's up to the plugin authors.

    *HeroChat and any other plugin calling Permissions.getPrimaryGroup() will throw an exception with SuperpermBridge - this might be fixed already I have been away for a few days.

    You can also do ": op" or ": notop" and the user will only get that permissions if you do /op on them. (Which is Vanilla's way of making people admins - since that's still present in CraftBukkit because it's based on vanilla, the new Superperms took advantage. Technically, if you just need admins and players, you don't even need PermissionsBukkit, you can just set everything up in permissions.yml and /op people who should have ops. Remember, Op gives full vanilla control too, like /stop for example.

    @SpaceManiac - Any word on a fix for this? Forgive me if I missed the response as I skimmed over the thread.

    EDIT: Looking at your source, SuperpermBridge is based on a Permissions 2.x branch - If you want full compatibility, shouldn't it be based on 3.1.6?

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

    SmartyGeek

    I knew you're not supposed to have tabs, but I thought I got rid of them all, so thank you! (Is that what to \t means?)
     
  21. Offline

    Jobsti

    heyho @SpaceManiac

    Plugins works, but bridge not fully.
    MCDocs doesn't work, and the old antigrief could not detect "permissions.build: true",
    so I can't use the old antigrief, but it's important for me.

    And herochat doesn't work too.
    Whats with the Bridge? I think the Bride should fully support all old plugins?!
    So it sould have a prefix and suffix and old build flag. Would be awsome, and the bridge would be perfect.

    Without Suffix, prefix and the old build-flags (Info: ), I couldn't change to the new permissions and have to use the old Groupmanager.
     
  22. Offline

    Grrrr159

    Plz get the converter for 3x! cant use this plugin without it
     
  23. Offline

    obscurehero

    @SpaceManiac
    Any plugin that doesn't have superperms support (ie...no plugin.yml), we need to put a superpermsbridge before all of our normal permissions nodes?

    that from the changelog seemed to be my clue, but I wanted to verify this. Otherwise, * is only a wildcard flag if it is declared as such in the plugin.yml or permissions.yml. Correct?

    Multi-world is supported via the world declaration of the groups definition. right?

    Finally, does the plugin auto-add users with a group to the configuration, or is this all manual.
     
  24. Offline

    grandwazir

    I have encountered an interesting bug with this and using Stargate. If I add stargate.create in a collection of permissions (for example plugin.stargate.creation) in permissions.yml and then add that to a group the permissions will not be found by stargate.

    The same goes for adding stargate.create to the group directly.

    If I add the permissions directly to the player or by setting it as default in permissions.yml stargate.create is found correctly.

    Not entirely sure what is going on there.
     
  25. Offline

    Bronski

    Gonna have to agree with that. I had to go back to another plugin because I couldn't resolve problems with PreciousStones (despite naming the nodes specifically) and trying the work-around nodes.

    Good luck with it. Hopefully this project gets us a step closer to sanity.
     
  26. Offline

    krinsdeath

    Only users that remain in the default group are not written to the disk. If you change them in-game (via /perm player setgroup [player] [group]) they will be written to config.yml.

    @Jobsti - Certain keys (suffix, prefix, info, etc) are irrelevant and are not permissions, and as such will not be added to Superperms. These keys need to be accessed from inside the plugin that uses them (or, in the case of being configurable, in that plugin's config.yml). This will take some getting-used-to on the part of plugin developers, I think, but it will make things a lot cleaner and more distinct when it comes to which plugins are doing what with which information.

    In the mean time, mChat will do what HeroChat was doing.

    Without a peek at your config.yml (and possibly your permissions.yml), I can't really say what the problem is. I'll do some testing, but it may be that you're configuring things improperly.

    edit: Tested this with PermissionsBukkit 1.1 and SuperpermsBridge 1.2 with the following file, and encountered expected behavior (it worked perfectly):

    Code:
    groups:
      default:
        permissions:
          superpermbridge.stargate.*: false
      users:
        permissions:
          stargate.use: true
          stargate.create: true
          superpermbridge.stargate.network.*: true
        inheritance:
        - default
    
    edit2: further testing
    permissions.yml
    Code:
    theAncients:
        description: all of the stargate creation nodes
        children:
            stargate.use: true
            stargate.create: true
            stargate.create.personal: true
            stargate.destroy.all: true
            superpermbridge.stargate.free.*: true
            superpermbridge.stargate.world.*: true
            superpermbridge.stargate.network.*: true
            superpermbridge.stargate.option.*: true
    
    config.yml (PermissionsBukkit)
    Code:
    groups:
        default:
            permissions:
                superpermbridge.stargate.*: false
        users:
            permissions:
                theAncients: true
            inheritance:
            - default
    
    Works as expected.
     
  27. Offline

    midget_3111

    First of all, I think this is a much needed change to Bukkit, a permissions system and Bukget being built into CraftBukkit in my opinion, are what CraftBukkit has been missing, and we're half way there!

    I have been following this thread from the beginning and must say I'm very impressed with the support SpaceManiac has been providing on here, I also think the plugin is very well thought out and easy to migrate to from Permissions 3.1.6, I'm currently running it at the moment, and the only problem I have encountered is the Multiworld problem that was mentioned earlier in the thread.

    Is there any more news on multiworld support?
     
  28. Offline

    Jobsti

    I want this only for the bridge for old plugins, not for superperms.
    Nope, some functions only have Herochat. Localchat, good Dynmap integration etc.
     
  29. Offline

    RustyDagger

    Default commands also has a chat formatting system some 1 should contact him about how to change the system over.
     
  30. Offline

    Gibstick

    Wonderful plugin! In fact, it is so great that I created this account just to tell you about a small bug:
    whenever a player is kicked, no matter from console or in-game, I get the message:

    The player is still kicked correctly and everything else works. I hope I'm not the only one with this bug, and I hope it's not due to a bad config.yml, but I can provide that if necessary.

    Plugins: Backup, IPNotify, LagMeter, LatencyTester, MCTelnet, PermissionsBukkit, WelcomeMe, xAuth
     
  31. Offline

    FunnyMan3595

    Am I completely missing something here, or is there no way to create a group from /permissions?

    /permissions player FunnyMan3595 addgroup mod -- Works
    /permissions group mod setperm superpermbridge.myplugin.* true -- Doesn't work, as the group doesn't exist.
     

Share This Page