Permissions FAQ

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

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

    Celtic Minstrel

    Not sure, but I imagine players have a method something like "attachPermission". Note that you won't need a Permission for this, only the string that is the permission's name.
  2. Offline


    Or just provide "ROOTNAME" and skip the ".*" That's what child permissions are for.

    Example: (open)
        description: Gives access to all myplugin commands
          myplugin.clear: false
          myplugin.create: true
          myplugin.destroy: true
          myplugin.list: true
          myplugin.use: true
          children: myplugin.clear.other: true
          default: true
          description: Allows clearing of myplugin
          default: op
          description: Allows clearing myplugin owned by other players
          default: op
          description: Allows creation of myplugin
          default: op
          description: Allows destruction of myplugin
          default: op
          description: Allows destruction of myplugin owned by other players
          default: true
          description: Allows use of myplugin
          default: true
          description: Allows use of myplugin owned by other players
  3. Yea, was thinking about doing this the other day. just adding my "multiverse.*" perm to "*"
  4. Offline


    Couldnt figure out how to add a permission to a player thro a plugin. Any helps please ?
  5. Offline


  6. Offline


    How do i get this plugin???

    How do i get this plugin?????

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


    EDIT: All problems requested help for fixed. Improper syntax + noob is the root of all evil.
  8. Offline

    Connor Mahaffey

  9. Offline


    I'm sure a bunch of players oppose to this idea, and I'm in too. There's no reason for a permissions API because we already have Permissions 3.1.6. If you just implement the old Permissions, we'll all stop ranting.
  10. Offline

    Connor Mahaffey

    Actually in the "poll" 80% of developers said they liked the new system. I am one of them.

    Though it is a good plugin, using Permissions 3.1.6 has brought me countless headaches. Why?
    - People are using some obscure version ("where the heck did you get 3.0 alpha?")
    - When there's a permissions problem, the console says its a problem in my plugin - and I get blamed
    - Its another library I have to implement

    Most of the people who dislike the new system haven't tried it. Implementing it in your plugin literally takes about 3 lines of code. They are a lot more powerful, and when a user screws up, they know it's because their permissions are wrong - not me. Plus, a user can actually use any Permissions plugin they want - it doesn't matter, I just have to do player.hasPermission(); For example I know someone made a plugin that eliminates yml in permissions - great for them.

    Honestly, I hope that in the future plugins will shift to the built-in permissions - and that new users will realize its the plugin system to get. Right now adoption seems to me to be about 50/50 for new users - I think a lot of them just search the forums for Permissions and Permissions 3.1.6 is what comes up.


    If you want to continue the conversation, message me or reply to the superperms page - more relevant than the FAQ.
  11. Offline


    I'm not sure if this is right or not, but from what I gather this is just an interface between a permissions back-end and the plugins that use permissions.

    Surprisingly I actually see this as a really good idea. The omission of groups etc allows permissions plugin developers to create whatever implementation they want without worrying whether it will work with the plugins that use permissions.

    This actually helps me with an idea that I want to implement, which is an RPG plugin with various classes. Each class will have a starting XP and a maximum XP. As the player gains XP in a particular class then they gain more permissions. Alongside that there will optional groups that will add/remove further permissions. This is entirely possible now without having to worry about getting all plugins to support it.
  12. Offline


    80%? I'm oppose to it. The old one is simple to hook into, and no mess-ups.
  13. Offline

    Celtic Minstrel

    The new one is even simpler to hook into.
  14. Offline

    Connor Mahaffey

    You don't need to hook into anything in the new one. It's built in to bukkit.

    Don't say you hate it till you've tried it ;)
  15. Offline


    With the new one all plugin devs need to do is
    if(player.hasPermission("some.pointless.permission")) { do something....
    No need to worry how it's implemented behind the scenes

    I think one of the sources for confusion right now might be the lack of full support for the new API. Currently about half the plugins implement the new API, and the other half still with permissions 3.x. What is really needed is for permissions 3.x to be updated to support the new API so that everybody can begin to use the same standard. Once that happens then there will be no need for bridges etc between different permission implementations

    EDIT #2:
    I've now written a tutorial explaining how plugin devs can implement the new permissions:
    There's also a section on how to write your own permissions plugin that sets permissions:
    Connor Mahaffey likes this.
  16. Offline

    Patrick Crespo

    While working with one of the latest builds, I noticed that putting a permission in plugin.yml, It doesn't show up when I call SimplePluginManager's getPermission() method. Is this intended? The reason behind it, is because I want to have user configurable drops and then add all the permissions to the child of one of the nodes I know exists, but when I try and get it, the Permission "dropParent" comes up as null. Hopefully I'm just stupid and am missing something pretty obvious.
    The code (open)
    The plugin.yml permissions section:
        description: Fruitful master permission
          fruitful.drop.*: true
          fruitful.command.*: true
        description: Allows access to all Fruitful drops
        default: true
        description: Allows access to all Fruitful commands
        default: op
          fruitful.command.reload: true
    And the line I'm calling:
    final Permission dropParent = pluginManager.getPermission("fruitful.drop.*");

    P.S. I am a programming noob, so don't get too technical on me. :)
  17. Offline


    Looking over your code, I see nothing immediately wrong with that. I'll go and test it out myself and give you the result if somebody else doesn't beat me to it ;)
  18. Offline


    This is absolutely ridiculous.
    First, bukkit comes out with a completely unneeded permissions support.
    Second, there are already several plugins that accomplish what this does and some of them do it better.
    Third, The Yeti's permissions recently got a huge upgrade.
    Fourth, there are very many plugins that support the old permissions and only a handful that support this. Now there is need for large amounts of useless bug reports for plugin writers, for permissions conversion, for learning an entirely different permissions structure, for great working plugins to break for no reason, and for extra hassle when they actually do get updated to this.

    Can anyone tell me one single upside to using this backwards method of adding permissions opposed to the old still updated more functional one? Why is this even needed?
  19. Offline

    Connor Mahaffey

    1. Wrong - central support is needed so plugin devs don't have to support a million plugins, and figure out problems with these plugins when users complain.
    2. I don't know of any plugins that support features like parent - child permissions
    3. Recently? I've been a developer since June and it hasn't been updated this entire time - not even recommended for build 1000 yet
    4. No one is forcing your hand except devs themselves. I've had no problems with PermissionsBukkit. The style is almost identical to old permissions except you need to add true/false to the end. As a dev I can tell you it literally takes 5 lines of code to implement Permissions AND PermissionsBukkit. 5 lines. No dev should complain about that - the Bukkit Devs change thousands of lines of code with every build.

    What's more PermissionsBukkit has a feature that "tricks" old plugins into thinking it's Permissions - so its compatible with just about everything.

    This is needed because there needs to be a central system. Adding the old Permissions support to plugins was difficult and buggy. When permissions is screwed up my plugins get blamed - that's when I get useless error reports. In just the last week 2 people were using some obscure version of permissions and complaining my plugin doesn't work. No problems using the Bukkit ones. Plus, it gives you one way to check permissions, and the ability to use any Permission plugin that supports it - there are already 2 different ones.

    The people who complain usually haven't tried it. Give it a chance. Tutorial:
  20. Offline


    You are absolutely ridiculous.
    First, the permissions support was absolutely needed. The fragmentation of permissions plugins is extremely frustrating for any plugin developer, and even for server admins.
    Second, this new system isn't necessarily designed to replace the old permissions systems. They are just supposed to hook into this new system. For example, PermissionsEx has already done this.
    Third, not everyone calls it an upgrade. I've heard many reports of it not being very stable.
    Fourth, it's not hard for a plugin developer to change to the new system. It's actually extremely easy for most situations. It might be a bit annoying right now, but once everyone switches over, we can move past all of this and everything will be much better.

    The upside is it makes plugin development much simpler. Developers don't have to worry about which permissions system their users are supporting, as their plugin will support any permission system that supports the SuperPerm system. This also makes it easier on server owners, because they don't have to worry about whether a plugin supports their chosen permissions system. Also, who says the old Permissions plugin is "updated"? It hasn't been updated for months now.

    Edit: ninja'd.
  21. Offline

    Connor Mahaffey

    Sorry, figured that would happen :p
  22. Offline


    If you're referring to registering a new account just to flame a new feature and accompanying API that not only doesn't break anything, but it far simpler to program for than manually supporting multiple Permissions plugins.. Yes. That is absolutely ridiculous.
  23. Offline


    I am sharing my opinion, call it flaming if you want but that just shows your ignorance toward others opinions.

    Yes while this may be all fine and dandy for developers its a tedious and time consuming process of transferring your permissions and also confusing on what to do.

    How is this in any way simpler? Permissions plugins have to update to superperms and then plugin devs for those plugins have to update to those plugins. Why not have a standard permission system that is reliable that is built in with bukkit, that way only developers only have to update to that built in system and users don't have to deal with confusion and lots of work to get it to work.

    Also, people developing plugins for these permission systems still have to deal with the "fragmentation" of them, the only difference is now the developers of the permission systems have to hook to a new api. How inconclusive. And this still means that there will be like 90 different permissions systems, and that plugin developers will still have to manually include these systems!

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

    Celtic Minstrel

    For me (in General) it was ~290 lines in plugin.yml and ~186 lines of code. :p But that's probably an unusual situation. It was a lot easier with SimpleSignEdit.

    No-one is forcing you as a server administrator to switch to a different permissions system. You should be able to just keep using whichever one you currently use if that's the one you prefer.

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


    Wrong. That is why it is simpler.
    I no longer give a crap what permission plugin you're using, because Bukkit takes care of it for me. As long as your permission plugin does things properly, it will work. My plugin doesn't depend on X permission plugin, I don't need X to build my plugin, I don't care when X changes versions, and X changing API doesn't affect my plugin in any way.
  26. Offline


  27. Offline

    Patrick Crespo

    Actually, I think I've singled it out. My 'setupPermissions' method was running during the onEnable call, and I think the PluginManager loads permissions afterwards, rather than before. I was getting IllegalArgumentExceptions after onEnable() when I addPermission'd them just fine during it. Which leads me to the next question, is there a reason why it needs to happen after that call as opposed to before? I mean, things like getDescription.getVersion seem to work just fine during onEnable.
  28. Offline

    Celtic Minstrel

    I think the IllegalArgumentException indicates that you're attempting to register a permission that's already registered.
  29. Offline

    Patrick Crespo

    Yes, but I was trying to set up permissions that I thought would be loaded already (a command to add extra permissions from items in the configuration during onEnable) but when I tried to get them, they were null rather than the permission. Only when I added them, and debugged it did I notice that the IllegalArgumentExceptions were thrown after the onEnable method finished (My permission adds had finished successfuly before then, so it's not those that were throwing it.) Which means that a function after onEnable was adding the permissions I thought should have existed in the plugin.yml, rather than before the onEnable.

    I mean, I worked around it by just removing the permissions from plugin.yml and everything didn't complain, but I was wondering why that happened after the enable, rather than before.
  30. Offline


    I'd like to request the function "getRegisteredPermissions()" which returns the map of all (currently registered) permissions. :) Or even just the key strings. I want the names of all the nodes that are set.

    Maybe a hook where I can read the name of the permission that was set...

    Why? Cuz I want to make BukkitPerms just that much simpler.
    Think about it, especially with the new "Pail" plugin, I could make a gui where operators could give/remove permissions to players without having to look up the permissions. You want bukkit to replace/succeed in permissions @Dinnerbone ? Make it simpler for operators to set permissions to players. ^^

    I mean, I could be ranting about something that already exists.. but I don't know. Don't think this does.

    EDIT: I feel like a noob now.
    Is this it?


    I'll be testing what all I get now... :)

    EDIT 2: Nope. Didn't get what I wanted.
Thread Status:
Not open for further replies.

Share This Page