bPermissions global groups.yml file?

Discussion in 'Bukkit Help' started by gabizou, Sep 19, 2012.

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


    So I moved over from PEX in the last month to bPerms simply because there were a few permission nodes that PEX wasn't negating to any of my users to some very dangerous plugins (like a plugin manager). Anyways, bPerms looked awesome, it would theoretically solve the issues of having permissions that I don't know about (because of the wildcards) and encourage me to know specifically what issues people could be having permissions wise.

    Plus bPerms supported multiworld global group perms and users files.

    That is where I have issues.

    I download bPerms and I get the config to set "use-global-files: true" and expect that the groups.yml file in the base bPermissions/ directory to work unanimously along with the users.yml in the same location. Successively, I've been able to duplicate issues where newly generated worlds (for use of dungeon instances), no permissions transfer over, the world generates a default group with no permissions and generates users in that default group, granting no permissions to do anything.

    Unless I'm doing something wrong with the config: http://pastebin.com/wWi5MuYb

    and the groups.yml file in bPermissions/groups.yml:http://pastie.org/4757609

    and the users.yml file in bPermissions/users.yml:http://pastie.org/4757612

    When I generate a new world called "test", and I teleport there, I attempt to type and Herochat reports: "You do not have permission to speak in World"

    I find this to be wrong in that from what I'm understanding a global groups.yml and users.yml file should be granting users permissions to their designated group no matter which world they are in?

    Unless I'm doing something completely wrong here in my interpretation.

    EDIT: This is also using bPermissions v 2.9.22, Vault 1.2.18 and Herochat 5.6.0
  2. Offline


    It's a little herochat glitch. You actually need to use the node herochat.speak.<channel name>
  3. Offline


    Not to be rude:
    If it were only Herochat perms, I wouldn't have minded the issue, but this is happening for any permission node. LWC, ShowCaseStandalone, etc. It's not plugin related, more bPerms not following global groups.yml perms.
  4. Offline


    Global doesn't get directly copied into it, but the global should be applied worldwide.

    gabizou if what you're saying is superperms aren't being applied in new worlds, that's important for me to know.

    Could you run some debugging commands for me?

    Teleport to that world

    /world <name>
    /user <yourname>
    /user has <permission>

    and report the output, it will report bPermissions API output as well as superperms output

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


    Here's your debug info as requested: http://pastie.org/4760697

    By the looks of the result, it does indeed look like SuperPerms aren't being applied from the global groups.yml.
  6. Offline


    Actually that methods check the world-specific perms.
    What I mean is TELEPORT to a world that you except not to work.
    The superperms output (is the expected output) aka :true because it's :true in global
  7. Offline


    So for bPerms api saying :false when superperms :true is intended? I mean I'm expecting the perm to be granted to me in all worlds if it's in global, unless I'm understanding the whole point of global group/user perms incorrectly.

    There isn't a world in which the superperms output isn't true because it's true in global.
  8. Offline


    Right, but the api check there queries the world-specific perms (which doesn't take into account global)

    Global *is* taken into account when applied to superperms though.
  9. Offline


    So how do I get players who start instances of new worlds like through TempleCraft to keep their permissions from global? I mean there's no way of knowing what the names of all the possible templecraft instances it will create, tis why I thought using global perms would keep the global permissions in all worlds whilst having the worlds that need changing having those changes per group.
  10. Offline


    "global" is like a seperate world, that is applied in all worlds.

    Think of it like this...
    Your total perms are the sum of both global and world perms. If you move to world_nether your total perms are the sum of global and world_nether perms.
  11. Offline


    So from that understanding, I should have bpermissions.admin in world_nether because I have it in global, right?
  12. Offline


    In superperms, yes.
  13. Offline


    but superperms is different from bperms? I'm slightly confused now. I thought the point of global groups was to grant those permissions to people in those groups universally?

    From what you're saying and what I'm understanding, any world that I teleport to I should have the same superperms as per the global group.yml but superperms don't necessarily default to true unless the world perms say so?

    Edit: Maybe it might help me understand better to give an example of what I want bperms to do specifically with examples.
    I mean, what I want is:

    -bpermissions.admin: true for me no matter what world I teleport to, because my permission group (owner) has the bpermissions.admin
    -herochat.speak.global: true for all members because that's what is defined in the member group permissions in groups.yml
    -scs.create.buy: false in world pvp for all users in the global members group (which I'm understanding is requiring for the user at time of promotion, be in the member group in that world with the ^scs.create.buy perm node under member

    Is this what's supposed to be the interaction between global groups.yml and global users.yml and the world groups.yml/users.yml?

    So a user who is globally in the member group should have the perm.node: true no matter what world they are in, negating permissions only if the world says so?

    So if a new world is created, I shouldn't have to rewrite all the perms into that world/groups.yml file if the bPermissions/groups.yml is being inherited to that world.

    I'm executing these commands in world:Tutorial with a clean bPermissions files (did set the config to use-global-perms: true)
    /world * - Global perms
    /group admin - creates the global group admin
    /user gabizou - selects me as a global user
    /user setgroup admin - sets me globally to the admin group
    /group admin - again selects the admin group
    /group addperm bpermissions.admin - adds bpermissions.admin to the global admin group.

    Now if I where to deop myself, I should expect to have bpermissions.admin: true in all worlds. Is that right or wrong? (this is my understanding of a global group permissions system with per-world permission customization.

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


    I'm more confused than before. I thought the point of "global.yml" is to apply perms to all members of a group specified in the global.yml - universally and dynamically. So, if a new world is created and a player joins that world, said player will still hold the perms which are held in "global.yml". Is this not correct?
  15. Offline


    that's correct yes, if this is not the case it's a bug and I will fix it.
  16. Offline


    Ok. Yeah, it's not doing that.
  17. Offline


    i haven't seen the actuall code...but i'm guessing if you have permissions loaded per world they would override the global...thats what fixed mine anyways...
  18. Offline


    I'm sorry but what?
  19. Offline


    i had permissions that conflicted each other set in both global and per a world...

    and i ended up deleting my global and setting each permission per world because the per world permissions would override the global...
  20. Offline


    Out of curiosity, any eta as to when that will be coming around?
  21. Offline


    Normal service will resume when I'm able to replicate the bug.

    From what you've said, create a new world, teleport to it, and you won't have global permissions in said world?
  22. Offline


    Well I noticed it in new worlds only because I set up per world permissions in the existing worlds. Now after lots of testing and fiddling, it doesn't matter what world, just superperms are not being followed in any world. A new log of exactly what's going on with just bPerms and Multiverse-Core (not even necessary) and a fresh set of configs, permissions, no ops etc.


    when I type /perm I get "[bPermissions] You're not allowed to do that!" even after the SuperPerms state I have the permission.

    Steps to reproduce on my end:

    1) start a fresh server with just bPermissions 2.9.23 (downloaded from BukkitDev)
    2) stop server
    3) change the config option "use-global-perms: true" in bPermissions
    4) start server
    5) in console: world *
    6) in console: group admin
    7) in console: group addperm bpermissions.admin
    8) in console: user gabizou
    9) in console: user setgroup admin
    10) in console: user has bpermissions.admin
    11) Verified that gabizou has the perm node from bPerms and SuperPerms
    12) in game: /perm
  23. Offline


    Thanks, that's really helpful :) I'll see what I can do about tracking it down and fixing it.
  24. Offline


  25. Offline


  26. Offline


    This isn't an issue over switching from pex. This is an issue that global permissions to groups (perms through SuperPerms) aren't being honored in all worlds as it should.

    Plus, I'm not looking for "Oh, here's a reason to switch back to PEX." I had very good reasons to switch out from PEX and I'm not looking for this type of guide to go back to PEX.
  27. Offline


    @codename_B Any ETA ? Would gladly use bPerms but I really need global files to work!

    Maybe you could do it otherwise: Just provide the global groups as inheritance source. E.g. define a global group "gadmin" and in a world define a group "admin" which inherits from "gadmin", that would be the most intuitive solution (for me)
  28. Offline


    codename_B Any reply whether this is indeed a bPerms problem or just user-error?
  29. Offline


    I had a similar issue.
    I used the mirror.yml and mirrored my world groups to all the worlds.
    This has fixed my issues, don't know if it will help you out until the global groups get fixed.
  30. Offline


    Thing is that for using plugins that make new worlds as instances, I kinda need either to plan ahead and make all copy folders for all possible instance named worlds or have global perms working :/

    Of course if mirroring could just do exactly that without me needing to enter all the possible world names, then awesome.
Thread Status:
Not open for further replies.

Share This Page