[Enhancement] Permissions API

Discussion in 'Plugin Development' started by Don Redhorse, Aug 14, 2011.

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

    Don Redhorse

    Bukkit and the plugins are great and all people concerned (developers, bukkit team, people helping in the forums) are doing a great job. But bukkit is on a rocky road and the usuability for the admin and user isn't at the point where it should be.

    This thread is ONE part of several threads, please do me the favour and read them all and only reply in here with information which help this thread become productive. Thanks..

    Bukkit has the following issues:

    Permissions... different plugins, different concepts, complicated, error prone and shattered
    Help.. complicated, not to the point, not really translatable / customizable.
    Aliases.. Complicated and plugin specific
    Forums.. Difficult to navigate and missing structures
    Plugins.. Plugin Standards allow for to many issues


    We have an permissions api since some weeks and coding for this api has speeded up, but there is also a lot of antimovement about it.

    Major complains are:

    No groups
    No Prefixes / Suffixes
    No Option Nodes
    No negative Permissions
    No Ranks
    and some more

    I think a lot of that comes from the way we did use the old permissions.. like using the suffixes and prefixes for chat, option nodes for configurations etc. And using the permission.yml to create überpermissions which in theory now substitute the groups wasn't perhaps a good idea without guiding the user (developers and admins) a little bit more.

    I think the new system is a good start and that perhaps some enhancements in the API can be made.

    So let's please start discussions here how to enhance the API, not how to recreate permissions.

    If you think we need prefixes and suffixes tell us why but also try to thing how it could be solved better, eg. chat prefixes suffixes could be solved with a changed config for the chat program which maps a right to a suffix / prefix. I know that is more complicated in the first act but are there any other scenarios this would be usefull? Is it really a permissions issue or more a chat issue? Couldn't groups and the capability to check the group membership be a solution?

    Negative Permissions and Ranks make life easier, but is that the role of the api to support it or should it come from the plugin which is managing those rights?

    Groups can be substituted with the permissions.yml but is it a good substitute?

    Do we perhaps only need a good howto move from permissions (and with this I mean the old permissions file structure) to superperms?

    Give us some feedback...
     
  2. I'd like to clearly point out that we talk about an API, and not a management system for privileges.
    All that bukkit permissions have to offer is what plugins directly have to access.
    This is currently more or less only checking if a player/permissible has a certain permission.
    Groups should not be provided IMO, that's managing permissions and no plugin has to access that.

    The only thing that I would really like to have implemented, would be values other than booleans (as some other guy mentioned somewhere).
    That would fix most of the issues that are listed in the op.

    Example usages:
    Code:
    myChatPlugin.prefix: Guest
    myChatPlugin.color: c
    myHomePlugin.gohome.cost: 100
    myHomePlugin.sethome.cost: 500
    theRankManagingPlugin.rank: 1
    And what exactly are "negative permissions" supposed to be?
     
  3. Offline

    Don Redhorse

    the true / false values on the permissions..

    the thread put's down a lot of assumptions... some are wrong ;-)

    groups are done by the "über"permissions in permissions.yml imho... but people need to get used to that.

    which means that with using the "über"permissions in permissions.yml you could do:

    groups
    ranks
    something else?

    already, problem is to find a permission manager which fully supports it.

    so I add another question to this thread.

    should all permission managers be required to fully support the api (at least to become an approved plugin I think the answer is yes).
     
  4. Offline

    Zeerix

    All permissions managers support groups.

    These plugins support Bukkit permissions:
    PermissionsEx, bPermissions, PermissionsBukkit

    EDIT:
    "support groups" here means you can have groups in the config file.
     
  5. Offline

    Celtic Minstrel

    Groups are certainly not permissions, so I don't see a problem with Bukkit not having an API for them. Still, a Group interface extending Permissible and some corresponding API might be nice.

    I don't think this belongs in Permissions at all. You could argue that it belongs in groups, but not in permissions. It's definitely not a permission.

    Numeric permissions would be nice. I don't really see the point in any other type, but there are a number of good applications for numeric ones. Perhaps someone can argue for string, list, or map permissions; I dunno.

    Negative permissions are there.

    I'm guessing this relates to a /promote and /demote command? That means it's the job of the group manager plugin to handle; it's not a permissions issue at all.

    Are you certain of that? Take integer permissions as an example. You could write utility methods that register and check integer permissions. I don't know how efficient it would be compared to Permissions options, but obviously if they use Permissions or PermissionsEx you can just defer to that instead. I have a vague conception of how it might work, if you're interested.

    Don't give up; maybe they can be convinced. They are human, after all.

    Which is of course not good.

    Forcing them to use all official APIs, sure. But frowning on those who ignore them where they probably should not, I can understand.

    Sure! :)

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

    Supersam654

    I have to agree with @Celtic Minstrel on this one. SuperPerms is an API and quite frankly, a lot people want Permissions to be "offfically integrated" into Bukkit. Instead of sticking with the old mindset of Permissions (which worked fine, simply because everyone used it so every plugin was built around that structure). I believe that the new Permissions system needs to simply be different, not a built-in copy. However, in order for this to work, I really think people need to let go of the old Permissions system, instead of migrating it. For example, I feel like ranting about prefixes/suffixes right now. WHY IS THIS INCLUDED IN PERMISSIONS!!! </capslock>. There really is absolutely no reason to include this. The concept (and because of it, the plugin "root" name) is called Permissions (or something with Permissions in it's name). The last time I checked, a permission is something that you either have, or don't have (hhhmmm, sounds like a boolean value and only a boolean value to me). A permission is not a number or a string, it is simply something that you either have, or don't have. If you want a permissions manager to deal with more than just whether or not someone has or does not have a permission, then you need a separate plugin. Just because Permissions did something poorly does not mean that SuperPerms should follow in its steps! If I want to give PERMISSION for a user to build somewhere, I give them a BOOLEAN permission. However, if I want to give that player a chat prefix...well there really is no permission for that. If you absolutely insist on using non-boolean values in permissions, then you need a config file that works in conjunction with the permissions.yml file. However, DEMANDING that a permissions system go far and beyond giving and denying players permissions is absolute insanity and it truly is time to break away from Permissions and move onto permissions and permissions alone.
     
  7. Offline

    Don Redhorse

    well the whole IT is based on users and groups, and sometimes even globalgroups, subgroups etc. but I agree that you don't need them if you use the "über"perms from permissions.yml as a substitute. People are just not used to that.

    Like I posted before, I just collected some statements from the forums on why superperms are not "good". As soon as people get there head around what superperms and the definition of it really is and when plugins start working around the "missing" features it will become easier.

    But like you said... there is / could be room for improvement and I want to collect those ideas here.

    Agree, and PEX and bPermissions allow it already iirc..

    but are superperms perfect?

    @Supersam654

    I agree, prefixes / suffixes could be solved by having a config file for the chat plugin which looks like this

    group: "über"perms.admin
    prefix: Admin
    suffix: none

    where group is just really a mapping to a permission from permissions.yml

    having the stuff all in one place like old permissions did was nice.. but didn't really make sense.. except it was easy, especially if you migrated from one chat plugin to the other..

    @Zeerix

    The permissions managers support groups, prefixes / suffixes etc.. yes but not permissions api.

    But I don't think the permissions api should support that.

    So anything the permissions api is lacking keeping in mind that it is focussing around permissions and not around additional information which is required for people having certain permissions?

    When the thread about persistance started I requested an extensible default schema to store information, one part of that schema would have been prefixes / suffixes.

    So perhaps instead of opening up the permissions api to support suffixes / prefixes etc we need an additional COMMON way to store this information so that different plugins can retrieve and use it?
     
  8. Offline

    Supersam654

    In case everyone isn't following all of the threads, I completely support the idea of only boolean values in Bukkit SuperPerms because quite frankly, the number 4 is simply not a permission for somebody. Instead, if you really need to associate non-boolean values with players, then "someone" needs to invent Bukkit SuperData for that, because the number 4 is a piece of data for a player (but by no stretch of the imagination is a permission).
     
  9. Offline

    Don Redhorse

    NICE :D

    So do you want to start discussion the Bukkit SuperData? Not in here though, perhaps you could start a thread and we try to figure out what we need.

    I just wander what the feedback of the bukkit team would be ...
     
  10. Offline

    Celtic Minstrel

    Well actually, you can't use permissions.yml as a substitute for groups unless you only want two groups. You can't use it to assign permissions to specific players, for example; all you can do is assign permissions based on whether a player is an op.

    So yeah, promote and demote are the job of the group manager plugin.

    I'm not sure what you mean here. PermissionsEx, bPermissions, and PermissionsBukkit all register their permissions with Bukkit using the superperms API.

    Like the Value pull request that @codename_B submitted, perhaps?
     
  11. Offline

    Don Redhorse

    hmm in this case I did misunderstand it... I thought you could create
    myownpermission.admins
    - whatever.whatever
    - herp.derp

    myownpermission.vip
    - hey.vip

    and use that in the normal permissions... at least that's the way I read http://forums.bukkit.org/threads/permissions-faq.25080/

    and I'm just wondering how the right syntax would be.

    IIRC Pex and bPermission support suffixes and prefixes via an own way... perhaps only for plugins that directly support them.

    no idea.. I'm a consultant for virtualization, desktop management and project management, no developer :p
    Supersam654 did a good suggestion... it would require a common structure / schema though
    if you want to you can read up some stuff I mentioned in bukkit persistance about schemas.. my pov mainly coming from eDir ...
     
  12. Offline

    samp20

    Personally I think the new permissions are great. On our server however we wish to use multiple permissions plugins. Firstly we want to use PermissionsBukkit to provide the standard group setup. As well as that though we also have a Jail plugin. When players are jailed we want to set some permissions to false and have them override the existing permissions. That's where the problem lies. Depending on the order in which the plugins get loaded depends on which gets priority when setting permissions. Ideally I think there should be the option to specify a priority when setting permissions, so that our Jail plugin can set permissions at higher priority than the permissionsBukkit permissions. When the Jail plugin then removes it's permissions the permissionsBukkit ones would take effect again.

    I think currently when other plugins wish to change permissions they have to do so by getting a handle to whichever permissions plugin is in use. The whole point of Superperms is to remove the need to latch directly into other plugins, which currently is still required in certain circumstances.
     
  13. Offline

    Celtic Minstrel

    It's true that something like that is possible; however, you still need a plugin to actually assign these permissions to specific players. If you're not using some kind of permissions manager plugin, the most you can do in permissions.yml is control the permissions granted to ops and non-ops.

    I was under the impression that the priority of permissions is based on the order in which the permissions are set. Which implies that what you want should already work as you want it, except perhaps if someone is in jail when you start up the server.

    I took a quick look at the Jail plugin though, and I suspect the issue may be that it does not support superperms; at least, the opening post doesn't mention anything about them.
     
  14. Offline

    samp20

    Currently the permissions are assigned in the order in which the permissionAttachments are created, which if set from an onPlayerJoin event could be in any order. Also the jail plugin I'm talking about is our own custom thing which you won't find on the bukkit forums.
    Also yea normally this should be fine since the jail plugin can define the permission attachment after permissionsBukkit, but for players in jail when the server starts, the outcome is undefined.

    I've actually sent a message to Dinnerbone about it, and he says that it's being investigated. It would be really handy if he did implement the idea, or some sort of alternative.
     
  15. Offline

    Don Redhorse

    hmm.. I would say that you need 2 things for that

    a) permissions being able to be changed on the fly
    b) a weight or rank for permission

    I think a) is already possible (except that some permission manager don't support it fully) but b) would be an enhancement or?

    Concerning permissions.yml... well that isn't described anywhere I think... I even had problems finding the syntax of that file as it is not in the faq thread for superperms but in the faq thread for bukkitpermissions.
     
  16. Offline

    samp20

    b) is exactly what I was thinking. Permissions plugins could have two choices for setting permissions:
    Code:
    setPermission(String name, Boolean value) #This uses the default priority
    setPermission(String name, Boolean value, int priority)
    That would allow existing plugins to function as normal, but gives the option to provide a priority if they wish.

    One thing that may be more complicated is how would you define weights within a config. This might be a solution:
    Code:
    some.permission: true
    another.permission: false
    yet.another.permission:
        val: true
        weight: 5
    the "yet.another.permission" defines two sub nodes with value and weight, whereas the first two are normal permissions
     
  17. Offline

    Celtic Minstrel

    However, this is up to the developer of the specific permissions manager plugin, so it's not something that needs to be worried about for the API.
     
  18. Offline

    samp20

    Well sorta. You don't need to worry about it for the API, but you've still got to consider how plugin devs can use the new features of the API. It's pointless adding a feature that nobody can work out how to use.
     
Thread Status:
Not open for further replies.

Share This Page