Permissions FAQ

Discussion in 'Plugin Development' started by Dinnerbone, Jul 7, 2011.

Thread Status:
Not open for further replies.
  1. As I said earlier, the FAQ simply says "you have no groups, no wildcards ok bye", without explaining properly what options we have instead.

    For instance, the only sane way of doing block group permissions is to dynamically load them all into a super node for that group and assign that to users (the option is the always favourite loop through every god damm permission to give that user). Which then begs the question of how unsetting/setting nodes which share children will be handled.
     
  2. Offline

    Celtic Minstrel

    I think unsetting a node with children will result in setting each of the children to the state opposite the one specified by the parent.
     
  3. Offline

    fugue2005

    do you ever intend to break the functionality of currently available permissions plugins within bukkit to force people to use bukkits permissions?

    having to add the 64 permissions nodes for minecartmania signs instead of just adding minecartmania.signs.* seems very counterintuitive.
     
  4. Offline

    Celtic Minstrel

    You should not have to do this, as long as Minecart Mania does its job properly. There may not be wildcards, but I think plugins will generally try to mimick the idea of wildcards.
     
  5. Offline

    fugue2005

    how then would i go about replicating minecartmania.signs.* without having to type all 64 nodes into a group.
    as the developer for minecart mania won't be back until september.
     
  6. Offline

    Zeerix

    If MM isn't updated to Bukkit.perms, it uses the old system. So where's the problem?
    If you use SuperpermsBridge by SpaceManiac, it has the option to mimic the wildcard behaviour.
     
  7. Offline

    Master2112

    But what if i don't want to use permissions on my server? can i just ignore it, so things will stay as they where before this? (most defaulting to either op or everyone)
     
  8. So a negated node would go to allowed? That's really great, people getting superpick where they shouldn't.
     
  9. Offline

    BattleGroundxx

    Your right he probably does not have time but I'm willing to take my chances and he he can not write the config file could you do it?
     
  10. Offline

    Techykid3

    I'm totally lost between what Superperms, PermissionsBukkit, and what the difference is :(


    Also, when we're on #1000 can we still use Permissions 3.0?
     
  11. Offline

    ToastedJelly

    This can't be right. It will return to the default behaviour which is returning false for everything... like when you never set the node.
     
  12. Offline

    xZise

    Ehr? Minecart Mania is a plugin which uses Permissions. Now why has Minecart Mania to bother with the wildcards? I mean, has the developer of Minecart Mania to add a permission minecartmania.signs.* and manually add all permissions? This is very prone for tiny copy & waste errors (added new permission and forgot to add it to the wildcard permissions).

    Instead this is the job of the underlying permissions plugin, to handle this.

    Fabian
     
    fernferret likes this.
  13. Offline

    ToastedJelly

    priorities?

    what happens if I assign those two permissions:

    Code:
    this:
      children:
        child1: true
        child2: false
    that:
      children:
        child1: false
        child2: true
     
  14. Offline

    Dinnerbone Bukkit Team Member

    If you assign "this" then "that", child1=false, child2=true. If you assign "that" then "this", child1=true, child2=false
     
  15. Offline

    ToastedJelly

    I see, does this happen because the order is kept or because the system throws the information away that these perms were set by this & that and only keeps track of the child perms?
     
  16. Offline

    Mhalkyer

    I'm still using Permissions 3.x without any issues.

    After 5 pages all I can say is..... UGG. I was definitely expecting Bukkit to implement a full-featured group management system and it sounds like this is just the bare bones API to storing permission nodes. I have to agree with @Mixcoatl , this is not the answer to my server admin woes.

    I still don't understand why Bukkit can't just absorb Permissions 3.x and simplify the commands to:
    /setgroup (add/remove) (player) (group)
    /setinfo (group/player) (node) (value)
    /setperm (add/remove) (group/player) (node)
    /addgroup (group) (default?) (inheritance)
    /removegroup (group)

    But I understand now this wasn't the goal and the new node system will help. I hope SpaceManiac's PermissionsBukkit becomes the standard because as a server admin I'm tired of having to keep changing plugins to do something that Hmod easily did over a year ago (no offense).

    One final question: Who actually would be modifying the permissions.yml file? Would that be done by Bukkit, Admins, or Permission-Management plugins like PermissionsBukkit?
     
  17. Offline

    Dinnerbone Bukkit Team Member

    Order is kept. In case of "this" then "that":

    Sets "this" to true
    Sets "child1" to true
    Sets "child2" to false
    Sets "that" to true
    Changes "child1" to false
    Changes "child2" to true

    (But of course it keeps track of them a little more in depth than this, so when "that" is removed the perms of "this" are in tact and child1=true,child2=false.
     
  18. Offline

    Raphfrk

    Could the function be emulated by having

    "group.groupname"

    permission nodes?

    "group.operator" would be a child of "group.admin"

    Being unable to change parent/child arrangements makes it less flexible though.
     
  19. @Dinnerbone

    So when a superperm is removed any children it shares are recalculated properly?

    That doesn't address group metadata issues, which is the ONLY thing groups are usually nessecary for outside of setting permissions
     
  20. Offline

    Dinnerbone Bukkit Team Member

    If you give a player a permission attachment and then later remove it, all permissions are recalculated and set to what you'd expect them to be without that attachment.

    Note that this is different to setting a parent permission to false through an attachment, that just negates the children.
     
  21. Well that's a nice feature. Seems the only real gripe now is the lack of a group level metadata API, for chat prefixes and such.
     
  22. So if i get this correctly:
    Permissions yml:
    Code:
    permissions:
        doorman.*:
            description: Gives access to all doorman commands
            children:
                doorman.kick: true
                doorman.ban: true
                doorman.knock: true
                doorman.denied: false
        doorman.kick:
            description: Allows you to kick a user
            default: op
        doorman.ban:
            description: Allows you to ban a user
            default: op
        doorman.knock:
            description: Knocks on the door!
            default: true
        doorman.denied:
            description: Prevents this user from entering the door
    This just enables the commands,, then i use a different plugin to define who can use them?

    If not how would i create groups in the permissions.yml?

    I had Admin, Mod, VIP, member and guest

    I Fail to grasp how to create groups
    But as far as i can see:
    Permissions:
    This states what the plugin is? --- doorman.*:
    description: Gives access to all doorman commands
    This states what commands/nodes the plugin uses? --- children:
    doorman.kick: true
    doorman.ban: true
    doorman.knock: true
    doorman.denied: false
     
  23. Offline

    4am

    This can be handled by the plugins themselves. The only thing you need the prefix for is chat display; the chat plugin's config can have a section as such:
    Code:
    groups:
      - mygroups.clan1 #this is defined by the admin in permissions.yml, it's just a flag for the group
          prefix: '[Clan 1]'
          suffix: '[The best!]'
          flood-limit: 10
          whatever-else: 'w00t'
      - server.groups.admins #or you could do it like this
          prefix: '=ADMIN='
      - moderators #even like this, but make sure you don't trample a plugin's name!
          prefix: '-mod-'
      - com.fouramsminecraftserver.groups.builders #this is probably safest
          suffix: '/b/'
    The nodes here don't need to be the ones I've assigned; you can use anything you want, including nodes declared by other plugins (as long as they'll only be true for that particular group). Remember, the example above shows a section of the config.yml of the chat plugin (HeroChat, iChat, whatever), and NOT the permissions.yml file, either Bukkit's or a permission manager's.

    This seems to be an attempt at a distinction between configuration and permission; which has the advantage of preventing confusion and mis-configuration; imagine a permission overrides a config.yml setting, or vice-versa (depends on how the plugin is coded!) unintentionally. If nothing else, it's a support nightmare for devs and downtime for the servers while the issue is resolved.

    I was thinking of recommending we set an unofficial standard of server.groups.whatever in permissions.yml for group flags, and then assigning those nodes true using your permissions manager of choice to the applicable group; but in reality, as long as the config.yml for plugins that need to determine groups are flexible enough to ask which node represents which group, admins can use any naming convention they prefer.

    On another note, I agree with some of the recent posts here, however, on the following issues:
    • How to we determine and/or set the permissions of offline users without accessing the permission-managing plugin directly? You could queue set-requests until the user comes online; but this is extra work with Persistence and would be much better handled as integrated with the API; this also doesn't solve the issue of querying an offline user's permissions.
    • How do we query for a list of users who have a certain permission, as opposed to querying for a node in relation to a specific player?
    If we can solve these two issues, SuperPerms is at least as powerful as current systems, and in reality is likely much more versatile.

    Nope, stop right there. This example you see is what goes inside a plugin to let Bukkit know what permissions the plugin is going to be using up-front. It's likely similar to what you can define in permissions.yml, however; I have not yet seen an example of a permissions.yml

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

    F4TSamurai

    Could somebody post a short example of a proper Permissions.yml? I keep failing when I try and set it up so that I don't have to type dozens of repetitive permissions in the config.yml for each group.
     
  25. Offline

    Cardmeister

    I apologize in advance for not reading all the posts at risk of repeating some of the information already provided. From what I did look at, there are a lot of questions and several scattered answers. I actually understand where the questions are coming from; I too felt I was missing something when I first found my way here.

    This next part is critical:
    This is why there is no built in "groups" support. Fact of the matter is, it does not even support assigning permissions to individual users. These are things that are left to be managed by the permission plugin(s).

    I highly recommend that anybody who feels they are missing part of the puzzle to visit the "default" permissions plugin by SpaceManiac, here. In addition to supporting the coveted "groups" mechanism, his post has a lot of excellent information about the permission system as a whole.

    Ultimately, this is a godsend for developers and admins, alike.

    Before:
    • Developers had to write extra code for every permissions plugin they chose to support.
    • Admins had to pass up certain plugins because it did not support the "right" permission plugin.
    Now:

    • Developers can implement permission support once and successfully interact with all (compliant) permissions plugins.
    • Admins can install whatever (compliant) permission plugin(s) they prefer without worrying about which plugins support which permission systems.
    I hope this puts some of the "fears" to rest. :D
     
  26. Offline

    imjake9

    This. Though I believe the new Bukkit permissions system is not without its flaws, most people who are ranting are simply missing what Bukkit permissions actually are. Bukkit has not created a way for server owners to create and manage permissions. It is only a developer API to allow plugins to check for the permissions of certain players.

    In order for Superperms to do anything, another plugin must actually manage what permissions are assigned to each player. The official "Bukkit-endorsed" plugin to do this is PermissionsBukkit, a plugin similar to the original Permissions 2/3 plugins. The syntax is quite similar, the only difference is that the underlying framework is managed by Bukkit. The only thing that server admins need to do is convert their old permissions config files to the new format. PermissionsBukkit even comes with a special companion plugin that makes plugins designed for the old Permissions systems work with Superperms.

    Now, for plugin developers it's a slightly different story. They will need to update their plugins to work with Superperms, but even this is a pretty easy task. Also, remember that you will not need to wait for plugins to update since PermissionsBukkit works with the old systems.

    Now, as for my own opinion on the system, I questions why we have it at all if it needs a plugin to do the assigning anyway? Is there some benefit of the new system other than simply standardization? I agree the Bukkit is a plugin API, and it shouldn't become bloated with features like hMod did, but then why have this system at all? Why not leave it to the plugins? Otherwise, though, I like the system a lot. Great work, Bukkit devs!
     
  27. Offline

    Dinnerbone Bukkit Team Member

    We don't implement it because there's hundreds of ways people want to toggle permissions; Giving perms for a certain region, giving perms for certain players, giving perms for anyone who's wearing golden armour. We leave all that to plugins to decide.

    We provide the api so plugins don't have to go around to all these other plugins (if they exist; remember, you don't NEED another plugin for permissions to work, op/notop work fine) to figure out what's what. They ask us.
     
  28. Offline

    7eggert

    You are looking at the interface that does not manage the permissions. At this side, you'll just ask "Has user 7eggert the permission to format the hard disk?". You don't ask directly if I am part of a group called Administrators, this is done by a backend. This backend is not part of bukkit so you can have a backend based on any privilege system, including group-based ones.

    Managing the users in a specific group would be the responsibility of the permissions plugin, too. I can see a problem there: How should a permission plugin know that I may grant e.g. wormholextreme.wormholes.mywormhole.use? (The permission name is wrong, but you get the picture).

    And while I'm at it, having a different role will be like changing the world, you'll possibly have completely different permissions.
     

  29. AH thanks, i managed to setup bukkit permissions and left permissions.yml unedited,, seems to work fine
     
  30. Offline

    xZise

    Hmmm,
    will there come also a possibility to delete a specific permission? At the moment, I'm trying to make my plugins working with this. But as there are no groups anymore, I wanted to switch to permission nodes. But when somebody removes a warp I want to remove the permissions specific for this warp.

    Fabian
     
Thread Status:
Not open for further replies.

Share This Page