The Permissions Plugin Debate Thread

Discussion in 'Bukkit Discussion' started by codename_B, Jun 26, 2012.

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


    Make your case for your favourite permissions plugin here!

    I feel like the debate over permissions plugins has kind of settled down now - so why not stir it up again?

    Those of you who are feeling brave, why not try another one and see what you think?

    Those of you who are feeling stubborn, why not post why you love the permissions plugin you use so much?

    Try to make your points clear, or at the very least, honest.

    Go! :)
  2. Offline


    the Question is why switch permissions plugin ?

    I use Pex which I find very easy and simple to use before that I used the one similar to Pex only reason i switchwas because it became out dated and unsupported.

    What i think is great now is that Dev can build with Vault/Register and hook into all permissions plugin without the trouble of just building to one permission plugin

    Personally I think all permissions devs should come together to build an awesome perms plugin but then agian each dev wants to-do things there own way

    just my 2 pence
  3. Offline


    Personally I think we need an all around better, global one that everyone uses, that would actually make sense and be easy to configure. When you scroll through the Bukkit Help forum, 50%+ of the threads are somehow related to permissions.
  4. Offline


    Actually 50% are related to pex :p

    How would you design an easy to use one? Maybe I can make it?
  5. Offline


    I like groupmanager, It is simple and easy to understand and use
  6. Offline


    I've used bPermission and PEX. Nothing against you Codename_B I just found PEX to be easier. You see I like others came from using permissions by Yeti. Well almost everyone did. The syntax or should I say the config layout just makes sense to me. They basically operate the same, but PEX just seems easy.

    Group Manager I found to be a pain in the bum. Way too many files to maintain. I just need one file for permissions.

    For beginners I think PEX could be easy and faster to setup.
  7. Offline


    Is the one giant file a good thing then?
    I could make bPermissions do that, I just liked the organisation of having everything setup per-world and separated into users and groups.

    One thing bPermissions has done which no other permissions plugins have done so far is pre-parse the yaml files and fix common errors for people (replace tabs with spaces, close unclosed strings, remove empty lines). I'd like to see other permissions plugins doing that too - it saves a lot of hassle when it comes to answering support tickets, that's for sure!

    bPermissions has a near-identical layout to permissions 3 (just a few minor word changes) and supports changing from permissions 3 with a single command (/permissions import p3) rather than having to copy/paste files.

    The main issue I have with pex is that it breaks on /reload

    Really though, what's the appeal of the one giant file?
    afistofirony likes this.
  8. Offline


    I don't know I just like one file. From maybe a programmers prospective multiple file each with there individual function makes sense, but from a user prospective I want one file. Thats just me. I did do some programming work a while ago, but I'm a noob with C/C++ and we did a lot with make files and organization was key. So I understand multiple files sort of works.

    You can do some per world permissions, but its a bit tedious because all the users have to be in that one file.

    bPermission is a good plugin, but its just not for me.

    Breaking on reload I'm not to worried about. As long as you know what you are editing reloading isn't really necessary. I know that large servers want to minimize restarts, but that is only a select few people who have at least 30-40 plus users online at the same time. I haven't looked a numbers for a while so I'm speaking of what I saw months ago.
  9. Offline


    Fair enough. Valid points, I guess you know where everything is!
    What would you think of one giant config.yml where every plugin stores their settings?
    Twenty-Four likes this.
  10. Offline


    I personally would like to see it where users are in one file, and the permissions are in another. I think one thing that permissions plugins could improve upon is just the basic functionality. I've never used per-world permission, and global permissions is something that some plugins don't instantly have available(mirroring or something weird like that). That was one of the good things with GroupManager.

    I've since moved on from Group Manager, and found the configuration for PEX to be pretty intuitive. But the commands for PEX are ridiculously long. I, as mentioned before like things simple. A nice and easy group switch would be greatly preferred over adding them to another group, and then removing them from their old one.

    I've hardly used bPermissions, but I've had mostly good experience with it. The ability to auto-generate permissions for some plugins is really nice, and really intuitive. I had a friend trying to set it all up, and all I had to tell him was to type a command.
  11. Offline


    So bPermissions (world-centric) commands are ok for you then you think?

    It does it like - say you wanted to set codename_B to admin in the global files?

    /w *
    /u codename_B
    /u setgroup admin

    If not - what command(s) would you like to use?
  12. Offline


    Yeah, something like that would be really nice. In PEX it's currently something like this:
    pex group admin user add evilmidget38
    pex group default user remove evilmidget38

    Maybe I'll switch to bPermissions. One thing I didn't mention before, is that bPermissions doesn't support - '*' for all permissions. That's a feature I really like, and sorely missed. I didn't want to have to go through and give admins every permission. People I know have had this same complaint. I'm assuming there's probably a reason behind this, though.
  13. Offline


    OP gives all permissions.
  14. Offline


    I know, but that requires /op, and then also they don't have a prefix unless I also add them to a group for admins. It all comes down to me wanting to do as few commands as possible, I guess.
  15. Offline


    I could make it auto-detect the * node and give anyone with that node op?
  16. Offline


    I think that'd be a good idea. Easier on you as the developer by far, and it gives the same result. What about if their rank is changed though? You'd need some method to check that only people who should be opped, are opped. Maybe disallow players being opped unless they have the permission node?
  17. Offline


    I personally experimented through all the permissions plugins, after yeti's permissions ceased living. I hate permissions in all honesty, it took a whole week of craziness on my server to finally get settled back in. I chose PEX, and had the damnest time getting it going. For one PEX's import function didnt work at all for my permissions file(which at the time had been generated and edited by McMyAdmin, which may have caused the issues. I looked at the so-called 'offical' permissions plugin and was disgusted by it. I have came to love the old permissions format and PEX continued it with a plethora of added features, like in-game permission adding. I hardly ever actually edit using the YAML file because I'm afraid I'll break it, like just yesterday I opened it and must've done something wrong, and broke my PEX, thankfully on startup it showed that the error was a missing space on line 519.
    Sum it up, I use PEX, but sorta hate it.
  18. Offline


    That seems highly insecure.. plus OP does not give all permissions all the time, it's based off of what you choose to default to in your plugin.yml.

    On that subject, there should be a way in your plugin.yml to "exclude" permissions from being included with the '*' node on plugins that support it. Too many pluins have permissions that you might not want (e.g. VanishNoPacket), and have to manually negate those permissions after adding the '*' node. A way to make it so that those normally unwanted permisisons aren't included in that by default (much like we can with permissions and OP's) would be great.
  19. Offline


    I would find it quite hard to leave bPermissions, I'm very used to it and I find it easiest to use as I had a ton of problems with PEX crashing my server, not loading or not working correctly.
    I just wanna say I love you codename_B <3
  20. Offline


    bPermissions :D Honestly I picked one pretty much at random but I do like it, even if the commands are a bit awkward and I had to add my own ;)
    rymate1234 likes this.
  21. Offline



    I use bPermissions, because honestly, I feel like it's the best permission plugin. codename_B (shout-out to you, thank you really much!) really listens to his users and bPermissions is probably the easiest one to use.

    I really like how it organises permissions as "buckets", instead of using "groups" like, for example, PEX.

    I can create a "ChestShop" (self-advertising : P) bucket, and give it to some of my groups (for example, for Traders and VIPs, but not Builders).

    This feature should really be more popular, because I like the "new" way of thinking about permissions.

    Also, I've had enough reports about PEX acting up, and this:

    is still not resolved, so I have to force my users to use a work-around.

    Now PermissionsBukkit - it feels too "static" to me. It still uses the "old", "group" way of thinking.
    GroupManager - haven't tried it nowadays, but I've used it before and it felt like Permissions 1/2/3.

    So, again, codename_B, I'm really thankful for bPermissions and the way it works (I'd probably say that's just like Apple's systems, but I'd be bashed for it - but yeah, it "just works", like Apple). It's the most standard-compliant plugin I know. Also, please, please make people more aware of "buckets in buckets" - that means creating a "bucket" for some plugin and then just assigning this "bucket" to some other "bucket - group". (This is probably not clear, though :p Sorry!)
  22. Offline


    I have no clue what a bucket is, but it sounds a lot like the built-in permissions.yml?
  23. Offline


    Well, "bucket" is something like "group" in normal permissions, but here it works a bit more flexibly (or I think this still exists, as I haven't been updating bPermissions for a long time - it's only a local server now, unfortunately :p)

    But yeah, permissions.yml with a bit of tweaks (because I can actually modify the groups live)
    codename_B likes this.
  24. Offline


    Yep, groups can have groups, players can have groups etc.

    Basically both players and groups are group carrying objects (from a code standpoint) so they both work identically.

    This does however mean you can have a group inherit itself and royally cock up your files (I deliberately didn't fix this as anyone who does this deserves the error)

    If you're really curious about how bPermissions works, check out the framework on github, the bPermissions api (which the code is based on) is totally bukkit free and has been ported to things such as the bPermissionsGUI (a project which reuses exactly the same bPermissionsAPI as is in the plugin, just in a different way!)

    And on a slightly related note, I knew I'd done some good code when I copied/pasted the api into the gui I wrote and it worked with no changes :)
  25. Offline



  26. Offline


    I prefer the way PEX works, instead of setting it to true and false and such. I don't know, I've just always liked it better. It does have some issues with /broadcast and /say in the console after a reload though... But thats my only complaint. bPermissions seems to be more confusing to me...
  27. Offline


    I deny all and substute it for SuperBukkit bPermissions3 Ex. (Please just standardize a system.)
  28. Offline


    How is bPermissions confusing?
    Please explain and I'll do my best to make it less confusing in the next release. Saying "it's more confusing" doesn't help me make it less confusing :(

    Example groups.yml
    #Specify the name of your default group here
    default: default
    #Groups list, this is the only other list that should be in your groups.yml
    #This line specifies the name of your group
        #You specify your permission nodes here
        - ^group.moderator
        - bPermissions.admin
        - bukkit.broadcast.admin
        - bukkit.broadcast
        - bukkit.command.kill
        - bukkit.command.list
        - bukkit.command.whitelist
        - bukkit.command.whitelist.reload
        - bukkit.command.whitelist.remove
        - bukkit.command.xp
        - tracks.*
        #Groups to inherit. This means admin inherits moderator's permissions
        - moderator
        #Meta data for prefix, suffix, and group priorities
          priority: '100'
          prefix: '&5admin'
        - bukkit.broadcast.user
        - group.default
        groups: []
          prefix: '&9user'
          suffix: ' Newbie'
        - ^group.default
        - bukkit.command.ban.ip
        - bukkit.command.ban.player
        - bukkit.command.ban
        - bukkit.command.kick
        - group.moderator
        - default
          priority: '50'
          prefix: '&7moderator'
    To me, that just makes sense. Groups have groups, groups have permissions, groups have metadata. It's all specified there.
  29. Offline


    Lol, bPermissions.

  30. Offline


Thread Status:
Not open for further replies.

Share This Page