The Ultimate Guide to Permissions

Discussion in 'Bukkit Help' started by ImminentFate, Jun 11, 2012.

?

Did you find this information helpful?

  1. Yes

    75.0%
  2. No

    25.0%
Thread Status:
Not open for further replies.
  1. Offline

    ImminentFate

    [​IMG]
    This guide will cover the basics of using multiple permissions plugins, to help you get to know them.
    The permissions systems that will be covered in this guide are (+more at request):
    Ones in green are done, while ones in red need to be started. Orange ones are halfway there.
    • bPermissions
    • GroupManager Bringing it back, as per multiple requests
    • PermissionsBukkit
    • PermissionsEx
    • SimplyPerms
    I will also include example configuration files for each permissions system, to help get you started.
    In each section, I will cover it as if I am talking anew. I will make no reference to other discussed plugins to save you the headache of reading through another article as well.

    General Information:
    We will be working with YAML files (.yml), which are very picky about syntax and use of characters. Here are a few things I would like to get straight first:
    • Use Notepad++ to edit your yml files. This editor makes everything look neater and offers more features that the original notepad.
    • NEVER use the TAB button when editing yml files. It breaks them. Instead of a tab, hit the space bar four times. (Some permissions plugins use two spaces to break up sections. This is explained in its section)
    • If you start the server and then make changes to the permissions files, you will have to reload before the changes show up in game.

    [​IMG]
    bPermissions uses the SuperPerms system to handle permissions. It has a simple, easy to use interface and also has a GUI for permission management.

    The files in bPermissions are split into two main ones: users.yml and groups.yml. Users.yml handles all user specific data, while groups.yml controls mass grouping.

    Groups.yml
    The groups file contains two main headings, under which everything will be placed.
    PHP:
    default:
    groups:
    The default heading indicates which group will be the default for new players coming to the server. If no default is specified, every user will have to be added to a group manually.
    The groups heading is where all groups to be made will go. It is important to note that tabs cannot be used in yml files. A space of two (2) should be used in bPermissions for separating headings from sub-headings.
    To start off, we will make a new group, and call it "Guest". We will also set our default group to "Guest"
    PHP:
    default: Guest
    groups
    :
      
    Guest:
        
    permissions:
        
    groups:
        
    meta:
    Take note of the subheadings under the group default, and note their spacing. Also note specifically the subheadings of groups and meta. We will come back to these later. For now, we will focus on the permissions section only.

    The permissions in bPermissions can be broken down into positive nodes and negative nodes. A positive node will give permissions, while a negative will deny that permission. Negative permissions are shown with a "^" before the permission. A wildcard node "*" can also be specified, if the plugin supports it. A wildcard will give a player access to all commands for that plugin, or subsection of the plugin.
    The permission node is always preceded by a "-" and is directly in line under the permissions heading. For the below example, a permission "bukkit.build" will be given to the group. The wildcard permission "bPermissions.*" will also be given. We will also specify a negative permission, "bPermissions.reload"
    PHP:
    default: Guest
    groups
    :
      
    Guest:
        
    permissions:
        - 
    bukkit.build
        
    bPermissions.*
        - ^
    bPermissions.reload
        groups
    :
        
    meta:
    Note the placement of the nodes relative to the subheadings. Also note that there is a space between the "-" and the permission node.
    The above will let the group build on the server, and have access to all bPermissions commands besides the reload function. Take note that deny nodes override allow ones.
    Now, let's make another group, this time, a moderator.

    PHP:
    default: Guest
    groups
    :
      
    Guest
        permissions
    :
        - 
    bukkit.build
        
    bPermissions.*
        - 
    bPermissions.reload
        groups
    :
        
    meta:
      
    Moderator:
        
    permissions:
        - 
    bPermissions.reload
        
    bukkit.*
        - ^
    bukkit.op
        
    - ^bukkit.ban
        
    - ^bukkit.unban
        groups
    :
        - 
    Guest
        meta
    :
    This time, we have specified that the group has access to bPermissions.reload, along with most of the default bukkit commands, besides "op" and "ban". You should note that the groups subsection now has a tag in it, saying "Guest". This shows that this group has all the permissions of the guest group, as well as the ones specified in its own permissions section. If we make an Admin group, and let it inherit the moderator permissions, it will get both the moderator and the guest permissions.
    PHP:
    default: Guest
    groups
    :
      
    Guest
        permissions
    :
        - 
    bukkit.build
        
    bPermissions.*
        - 
    bPermissions.reload
        groups
    :
        
    meta:
      
    Moderator:
        
    permissions:
        - 
    bPermissions.reload
        
    bukkit.*
        - ^
    bukkit.op
        
    - ^bukkit.ban
        
    - ^bukkit.unban
        groups
    :
        - 
    Guest
        meta
    :
      
    Admin:
        
    permissions:
        - 
    bukkit.ban
        groups
    :
        - 
    Moderator
        meta
    :
    Anyone in the admin group will have access to all the moderator commands and the Guest commands. You may wonder about the deny tags. Those do carry over in inherited groups, but if there is a permission allowing it in the end group, then it is allowed.
    The order of importance carries that if Guest is denied a permission, and Moderator inherits that permission, then moderator will be denied that permission. But if moderator is allowed the permission, and inherits the denied permission, then it will be allowed it anyway.
    That's all there is to know about the groups.yml file for now!

    Users.yml
    The users.yml file is where user specific management occurs. This allows you to set individual permissions and meta for each user, in case you want someone to have slightly more privileges, or remove certain features from only one person. The default file looks like this:
    PHP:
    users:
      
    imminentfate:
        
    permissions: []
        
    groups:
        - default
        
    meta: []
    The users.yml file will automatically be populated with the names of people who join the server. Those square brackets "[]" can be ignored. they specify that there is nothing in that section.
    In this section, any user specific operations can occur. This will work exactly like the groups.yml, except for one person only.
    That is all you need to know about the users.yml file.
    Other Files:
    bPermissions does have other files, including tracks.yml and mirrors.yml. You don't need to bother yourself with these right now, and they will be discussed in the more advanced tutorial.
    GroupManager:
    [​IMG]
    PermissionsBukkit is the Bukkit Approved permissions handler that came out very quickly when SuperPerms (Bukkit's own permissions API) was announced. PermissionsBukkit works slightly differently to other plugins, in that rather than using symbols to specify an allowed or disallowed permission, it simply uses a "true" or "false" statement at the end of each permission. This permission handler can get complex, but as with bPermissions, I will only discuss the basics here.

    PermissionsBukkit doesn't confuse the rookie Server owner with multiple files for each world. Instead, permissions are handled from only one file: the config.yml found in the PermissionsBukkit folder that gets created on launch.

    When this file is opened, A whole bunch of green text (or some other colour. If the entire document is in black and white, get yourself Notepad++) will be shown at the top of the document, explaining how to go about using some of the features that PermissionsBukkit has to offer. Which is all fine if you know what they're talking about! It does have a decent attempt at helping you understand what goes on, but many a user can still be left confused.
    Here's the rundown of how the file is broken up:
    • The help guide (the green stuff)
    • Users section
    • Groups section
    • messages section
    • debug section <---- can be ignored for now
    Users Section
    You may notice that there is already a user node in there, all set up for you. We will use it as an example:
    PHP:
    users:
        
    ConspiracyWizard:
            
    permissions:
                
    permissions.exampletrue
            groups
    :
            - 
    admin
    As you can see, every subsection is spaced out by four. NOT TABBED. Make sure to never use tabs in yml files. It breaks them. So, you will see that the username (ConspiracyWizard) is four spaces from under users and permissions is four from the username and so on. This spacing is important. Don't disregard it.

    Now, have a look at the layout of the permissions. You may notice, as I discussed before, that the node has a "true" statement after it. That means the permission is allowed. If it was false, it would be disallowed. Again, spacing is important. Make sure there is a space between "true" and the colon ":". The groups subsection defines what group that user belongs to. these flags are NOT spaced out by four, like the other ones. they sit directly under the subheading.
    Most of the time, the users.yml file doesn't need to be used. It only comes in handy if you are specifying an additional permission for someone to have, or decide someone specific no longer deserves a privilege.
    Here is another example users section, using permissions from @sk89q's CommandBook
    PHP:
    users:
        
    ImminentFate:
            
    permissions:
                
    commandbook.weathertrue
                commandbook
    .bans.*: false
                commandbook
    .teleporttrue
            groups
    :
            - 
    moderator
    In the above example, I have used a "*" node, also known as a wildcard. This means that any sub-permission of that group can be used, and saves you typing them all out. You must note, however, that wildcards are not supported globally. Individual plugins must define this type of permission themselves for use. If you were to type each command out individually, it would take time. Now, what if you wanted to give someone every permission, besides a few? Well, you would use the same principle, except set a false permission on the ones you didn't want them to have. Deny always overrides allow. Confused? Here's an example:
    PHP:
    users:
        
    ImminentFate:
            
    permissions:
                
    commandbook.*: true
                commandbook
    .teleportfalse
                commandbook
    .kickfalse
            groups
    :
            - 
    moderator
    This will give ImminentFate every CommandBook permission besides "teleport" and "kick".

    Under the groups subheading, you simply specify what groups you want that user to belong to. You can specify more than one, but don't go so far as to confuse yourself. Better stick to one group per person for now.
    Groups Section:
    This section is used to specify groups that players can be put into. It is split up into the following subsections:
    PHP:
    groups:
        
    groupname:
            
    permissions:
                
    permissions.exampletrue
            worlds
    :
                
    exampleworld:
                    
    permission.worldspecifictrue
            inheritance
    :
            - default
    The groupname is a simple identifier as to what the group should be called. That's it.
    the permissions section works exactly the same as the permissions in the users section, except that they apply to everyone in a group, as opposed to just one person. Everything else remains the same.
    The big differences are the "worlds" sub-heading and the "inheritance" subheading.

    The worlds subheading defines any specific permissions that you want to have applied to a specific world. For example, if you are using a multiworld plugin, you may not want everyone to be on survival in a creative world, and vice versa. This can be set using world specific permissions. First, the worldname is specified (this is the name of the world folder) and then permissions are entered in underneath, as per normal.
    The Inheritance section is actually not as hard to understand as it may seem. It simply signifies what other groups should be used to get permissions from as well. Think of a real life inheritance situation. If your grandmother leaves your mother a diamond necklace, they will both, at some point in their lives, own a diamond necklace. The same principle works here, except both groups keep the permissions. Here is an example, using two groups: The first group is a "player" group. the second is a "moderator" group. To save typing out all the permissions for "player" again in "moderator", the player group is simply inherited.
    PHP:
        players:
            
    permissions:
                
    commandbook.afktrue
                commandbook
    .home.settrue
                commandbook
    .home.teleporttrue
                commandbook
    .rulestrue
                commandbook
    .motdtrue
                commandbook
    .spawntrue
                commandbook
    .introtrue
        moderator
    :
            
    permissions:
                
    commandbook.bans.*: true
                commandbook
    .kicktrue
                commandbook
    .godtrue
                commandbook
    .teleporttrue
                commandbook
    .teleport.othertrue
            inheritance
    :
            - 
    players
    This shows that the group "moderator" will get all the permissions specified, plus the ones that "players" has. Of course, you could simply copy and paste the permissions over and over, but what happens if you want to change one thing? Inheritance makes it easier. Also, if the "players" group has a false permission for one thing, but the "moderators" has that same permission as true, the moderator one will be dominant. [Bad Scenario] If a small lizard comes up against a big crocodile, and the crocodile eats the lizard, the crocodile will gain what the lizard had, but will not become small. [/Bad Scenario]
    You should also note that if the inheritance is set to "default", that means that all newcomers to the server will be set to that group. Make sure to only make one group inherit "default".

    Messages Section:
    I'll leave this for the advanced tutorial, as it's not really considered "basic knowledge". More topics like parent and child nodes, prefixes and suffixes, color codes, variables and such will also be discussed in the advanced one.



    [​IMG]
    PermissionsEx is the forerunner to the old Permissions2/3 systems, and has many features that come with it as a package, including the ModifyWorld plugin and ChatManager. The ChatManager will not be utilised in this tutorial. However, a brief overview will be given of ModifyWorld, as it provides finer adjustments to be made to the gameplay.
    PEX utilises the SuperPerms system natively, along with most plugins these days. This permissions plugin also combines the "users" and "groups" breakdown into one file, for ease of use.

    When downloading the plugin, it comes in the form of a zip archive. Inside the ZIP are three plugins:
    • permissionsex.jar
    • modifyworld.jar
    • chatmanager.jar
    Extract these into the plugins folder of your server, then run the server once to generate the files. Stop the server after everything has loaded, and open up the permissionsex folder.
    Inside, you should see two files.
    • config.yml
    • permissions.yml
    The config.yml handles a few configuration settings. This file can be ignored in this tutorial.
    The permissions.yml file should look like so:
    PHP:
    groups:
      default:
        default: 
    true
        permissions
    :
        - 
    modifyworld.*
    users: {}
    If you do not see the "users: {}" section, that's fine. It will generate once a player logs in, or you can create it manually. The curly brackets that appear after are there to tell the plugin nothing is in that section. Once you put something in there, you remove the brackets, as with the groups section.
    As you can see, every subsection is spaced out by four. NOT TABBED. Make sure to never use tabs in yml files. It breaks them. So, you will see that the group (default) is four spaces from under groups and permissions is four from the group and so on. This spacing is important. Don't disregard it. Permission nodes appear directly in line with the "permissions:" heading.
    Groups Section:
    The groups section is where group settings are made and controlled. Groups are used to combine a lot of people into one collective section, where a change can affect them all.

    Lets go through the lines in the groups section, one at a time:
    PHP:
    groups:
      default:
        default: 
    true
        permissions
    :
        - 
    modifyworld.*
    The first line indicates the section. This is the "Groups" section obviously. The two other sections possible in PEX are "Users" and "Worlds". Worlds will not be covered in this tutorial.
    The second line, spaced out by two from under the groups heading, is an actual group. This group is named "default", but that doesn't mean everyone will automatically join it on first login. The next line tells us this information.
    This line (3) is spaced out by two from under the group name, for a total spacing of four from the margin. This section determines whether a group will be automatically joined by newcomers or not. Note that only one group at a time can have this set to true.
    Then we have the actual permissions section. Here is where most people make errors, and problems arise.
    Firstly, permission nodes do not get spaced out from under the permissions heading. They stay in-line with it. Also, not the "-" before the actual permission. This is like a bullet point, and is used by the plugin to tell that there is a permission coming after. There is also a space after it.
    Secondly, There are three types of permission nodes that can be used in PEX.
    • Allowed Permissions
    • Denied Permissions
    • Wildcard Permissions
    Allowed permissions give a player a certain permission. Denied permissions prevent a player from using a command, and is especially useful when using wildcards. WIldcards are indicated by the ".*" on the end of them. This signifies that everything that falls under that permission node (or sub node) is allowed or disallowed. There is a wildcard in the example above.
    Allowed permissions are simply denoted as "- permission.something". Denied permissions are exactly the same, but with a negative sign "-" before the permission. Remember, there is already a negative there, but that's the bullet point. Adding a second one will make it a negative node. Wildcards can also be used with negative nodes or positive nodes. Here is an example:
    PHP:
    groups:
      default:
        default: 
    true
        permissions
    :
        - 
    bukkit.*
        - -
    bukkit.op
        
    modifyworld.*
        - 
    commandbook.*
        - -
    commandbook.weather
        
    - -commandbook.bans.*
     
    In the above example, the default group can use all bukkit commands besides the "op" command, and they can use all modifyworld features too. They can also use all commandbook features besides changing the weather, and if you notice, there is a wildcard after the next permission, "commandbook.bans". This is because the bans section in commandbook is broken down into kick, ban, unban, and banip. We could have written it like this:

    PHP:
    groups:
      default:
        default: 
    true
        permissions
    :
        - 
    bukkit.*
        - -
    bukkit.op
        
    modifyworld.*
        - 
    commandbook.*
        - -
    commandbook.weather
        
    - -commandbook.bans.ban
        
    - -commandbook.bans.unban
        
    - -commandbook.bans.banip
        
    - -commandbook.bans.kick
        
    But its a lot neater and easier to read if it is all grouped together. Take note that a negative node always overrides a positive one. That means that if you say:
    PHP:
    commandbook.bans.kick
    - -commandbook.bans.*
    The person can't use the "kick" command, because they are denied it by the next line.
    TO BE CONTINUED.....


    [​IMG]
    Taking a break from typing this, I will be back very soon with more content! Also, you may wonder why I never talked about meta tags in this example. That will be available in the Advanced (Intermediate?) tutorial which I will release after I get a simple one done for all these plugins. I haven't used all of the permissions plugins before. However, I will use them all, and test them all out before posting a tutorial so that I know what I'm saying actually works.
     
  2. Offline

    Thom_Ryan

    Great tutorial! Can't wait for PermissionsBukkit! :)
     
  3. Offline

    codename_B

    There is no bPermissions.reload permission just fyi - there's only one - bPermissions.admin
     
  4. Offline

    ImminentFate

    I know, I was just using it as an example :p
    i had to try something without confuzzling people over where other plugins came into it.
    btw, did I get all the priorities right on the group inheritance?
     
  5. Offline

    codename_B

    As far as I read you didn't touch on a multigroup setup?
     
  6. Offline

    ImminentFate

    I didn't think that was necessary, as this is for beginners. I was planning on putting it in an advanced tutorial. Unless you think its important here?
     
    ms2596 likes this.
  7. Offline

    codename_B

    Nah - but thats what priority means to me :)
     
  8. Offline

    Sayshal

    *cough* you should '-snip-' your first reply to this thread so people can see the others*cough*
     
  9. Offline

    Omnitv

    Good thread, Will use as reference. Cookie for you ImminentFate
     
    Lolmandan1208 likes this.
  10. Offline

    CodedPixel

    Great Job people have been having trouble with permissions a lot lately.
     
  11. Offline

    teetor

  12. Offline

    ImminentFate

    i am deeply saddened that you would even consider using my tutorial in your own thread. It grieves me greatly to see that the world has come to such, that a person would steal, and reference, without consent from the original author. This is a major issue today, as I'm sure we all know. People pirate games, and videos and music, and have a disregard for the feelings of the original author or creator.
    Shame on you, for automatically assuming rights to the re-posting of this information. Shame on you.
    In other words, go ahead :p

    thank 'ee very much

    PermissionsBukkit tutorial now up!

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 26, 2016
    ms2596, Blacksmithkazuma and teetor like this.
  13. Offline

    teetor

    So I can? xD
     
  14. Offline

    BladeFury1789

    Still dont really understand permissions at all. Is it a downloadable .txt file that you can edit to give ranks with certain commands? Also, the spawn radius on my bukkit is 16. Does that mean like 16 chunks? Cause it's obviously farther than 16 blocks.

    Also, how do I get iconomy do to more than /iConomy which shows my balance? Btw you kinda linked me here saying to use GroupManager and then didn't include a tutorial.

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

    ImminentFate

    i decided groupmanager didnt need a tutorial. If you just read the files it creates, it gives you enough info. It practically sets everything up for you.
    And as for iConomy, you need to give them the permission nodes for extra commands.

    yes, you can

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

    teetor

    Need 2 update ur part!
     
  17. Offline

    ImminentFate

    ? Don't get what you mean.
     
  18. Offline

    teetor

    Don't worry...
     
  19. Offline

    Omnitv

    Good thread, should be completed soon, and that helps others aswell. Cookie approved. will use as reference.
     
  20. Offline

    ImminentFate

    That's two cookies from you :p
     
  21. Cant wait for the PEX area to be completed, might clear some things up for me.
     
  22. Offline

    cleafspear

    this page is in my faveroites now.thank god for posting this, i could not figure out how to set this up for my server
     
  23. Offline

    ImminentFate

    not sure when i will get that up, but should be in a few days (maybe tuesday or wednesday). Quite busy, even though the holidays start on friday.
     
  24. Offline

    Omnitv

    I am bumping this before i sleep.
    Reason: It is relevant to the community.
     
  25. Offline

    ImminentFate

    Lol :p

    also everyone, sorry for the massive delay in the PEX tutorial, been feeling like crap lately and had no Internet for the past week. I'll get onto it pretty soon
     
  26. Offline

    Omnitv

    Oh, hey welcome back. I thought you were on summer vay-cay
     
  27. Offline

    Omnitv

    Explosion!
     
  28. Offline

    ImminentFate

    The no Internet part was while I was on vacation, but I also got sick while returning home
     
  29. Offline

    Omnitv

    A Little Cock Sparrow​
    Sat on a tree,​
    Looking as happy​
    As happy could be,​
    Till a boy came by​
    With his​
    Says he, "I will shoot​
    The little cock sparrow​
    "His body will make me​
    A nice little stew,​
    And his giblets will make me​
    A little pie too."​
    Says the little cock sparrow,​
    "I'll be shot if I stay,"​
    So he Clapped his wings​
    And then flew away.​
     
  30. Offline

    Necrodoom

Thread Status:
Not open for further replies.

Share This Page