My Struggle

Discussion in 'Bukkit Help' started by codename_B, Dec 31, 2011.

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

    codename_B

    Nothing sums it up better than this: "It's not that PEX handles wildcards better, it's that bPermissions doesn't handle wildcards at all. The only time the wildcard node will work in bPermissions is if that plugin is still using Permissions 2.X bPermissions has group inheritance in 2.0."

    So it's come down to this, bPermissions must do exactly the same as PEX in order to keep people happy.
    Superperms was a nice idea, but no-one is totally happy with how it works and it could be improved upon, but won't be.

    If I want bPermissions to handle permissions how I think they should be handled, it requires me to override the default system in place, which, while possible easily a definite hassle and requires supporting extra things for it to work with systems such as Spout.

    The only thing bPermissions does different than PEX now is to have different files per-world (which some people see as a bad thing anyway).

    I'm considering hanging up my bPermissions shoes, thanks superperms!

    What I'm looking for is feedback from bPermissions users, suggestions from devs, anything really.

    NOTE: I probably won't hang up my bPermissions shoes, so don't worry about that, I'm just annoyed that I keep banging my head against this same wall over and over again.

    Also @t3hk0d3 you were doing it right all along, keep things up YOUR way.

    EDIT: Update on my situation, I will no longer be writing for Superperms. People should write for the Vault API and no other.
     
  2. Offline

    MiracleM4n

    I sense anger...

    EDIT: Sorry I had to. I also agree SuperPerms was all nice and good at inception, but I see it as unfinished and lacking a lot (of which will most likely never get added).
     
  3. Offline

    mindless728

    i prefer the different permissions files per world

    all in all

    Keep up the good work!
     
  4. Offline

    Sleaker

    The issue is that SuperPerms (and rightly) allows a player to have a permission, but have it be false. This is different then not having a permission. And similar to negating a permission. Last I checked negated permissions just removed the permission from the player instead of adding it as false. This breaks functionality with plugins that need to check if it's true/false, not if they have/not have it (inversion makes a huge difference here).

    This is one major advantage of SuperPerms over PEX/P2 codebase. Because of how they handle permission assignment they can't handle inversion properly.

    Now * permissions are another matter. After a while of looking at the difference, I see * permissions as a non-issue. and a lazy-out for people that don't want to take the time to configure their server/plugins properly. Now it would be nice if there was a simple way to add all registered permissions onto a player and then be able to re-add ones you don't want an admin to have access to by setting them false. This would be the obvious next-step progression, but this can be easily achieved through a superperms compatible plugin by just grabbing all registered permissions in bukkit, and adding them to the player, then setting the ones that need to be removed/negated to false.

    I think Permission plugin authors are approaching the issue the wrong way. They see the legacy permissions and immediately think that the answer is to copy the internals identically instead of looking at ways to produce a similar result, (but WAY more powerful).

    What's stopping a permission plugin from registering a base permission '*' that holds all permissions registered (and set true).

    From a server/admin standpoint PEX often does things very very wrong. Simply changing the format/compatibility because it 'doesn't like how bukkit does it' - this is not a good way to run the plugin and is detrimental to plugin hooks.
     
  5. Offline

    codename_B

    You can check out the new bPermissions API on my github, the implementation is not done yet but I decided to put the WIP up there so far.

    https://github.com/codename-B/bPermissions/tree/master/src/de/bananaco/bpermissions/api/

    Basically it's non-superperms (at the minute) but has a method to return a Map<String, Boolean> of permissions, which can easily be added to a PermissionsAttachment.

    Feel free to pull request things if you feel so inclined, I accept 99% of pulls.

    Anyway, redesigning from scratch makes you come across lots of issues that you wouldn't otherwise come across, that's the problem with constantly trying to innovate I guess!
     
  6. Offline

    Kainzo

    I agree with Sleaker mostly about the '*' permissions, except for plugins like Herochat 5.0 where users create channels and in order to speak in them they would require '*' unless I missed something in the setup.

    So it's either to negate the nodes you don't want players to speak in.

    codename, you've done a good job on bPerms thus far, it's still is the best alternative to SuperPerms.
     
  7. Offline

    croxis

    IIRC * nodes can be defined in plugin.yml? Why not redirect the blame to plugin authors ;)
     
  8. Offline

    codename_B

    See my ticket list on bukkitdev :/
     
  9. Offline

    Sleaker

    this is the proper response, and not only that, but there's nothing from stopping someone from defining their own permission groupings or changing a plugins group to include the .* - open up the jar -> edit the plugin.yml add .* -> profit!
     
  10. Offline

    c0mp

    Not that your method wouldn't work, but isn't that what CraftBukkit's permissions.yml file is for? I believe it allows you to set parent nodes for a group of children, allowing the creation of the plugin.* node. Course, I could be way off base here, don't really use the permissions.yml file for our server, so my apologies if this is not the case. ;)
     
  11. Offline

    Sleaker

    I think it does too, though I've never used it.
     
  12. Offline

    codename_B

    Unless there's a gui for it, it's a nice idea but 99% of server admins will never use it.
     
Thread Status:
Not open for further replies.

Share This Page