bPermissions global groups.yml file?

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

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


    you can just copy & paste on every world.. it's easy
  2. Offline


    I'm still testing this, but this is probably a "me" error.
    If it is a "me" error, expect a fix by the end of the week.
  3. Offline


    Not to be impatient but any updates on whether it was a "me" issue? I know Bukkit is updating to 1.4.2 as we speak and dev versions have finally started rolling through for people to take their jabs at testing and starting to update plugins, but I just wanted to know whether the issue is anywhere close to being resolved ;)
  4. Offline


    I'm only one guy - and I'm very busy atm. I'm sorry :(
  5. Offline


    That is the problem. Even with "use global files" set to true, bPermissions seems to only grant your group/permissions if they match the world that you are in. This makes global files useless (keep in mind I'm using 1.4.2 as well, but I recall this problem in 1.3.2 as well).

    Here are the tests that I ran:

    Using groups default and beta1:

    - Set my group to beta1 globally (world *).
    - Checked the global users file, I'm in the group.
    - Checked my world file, I'm not in the group.
    - I have no prefix and no permissions, even though I've set "use-global-files" to true.

    Next, just to make sure:

    - I set my group to beta1 in the world I'm in (also in global)
    - Everything works as intended.
    - I set my group to default in the world I'm in (still beta1 in global)
    - I have no no permissions (but I have my prefix...), even though I've set "use-global-files" to true.

    So the strange thing there is that after I was able to get my prefix and permissions, I lost my permissions when I changed only the world file to default, but I kept my meta from the global files.

    Here's my final test:

    - I set my group to default globally (while it's still beta1 in my world)
    - I have both my prefix and my permissions.. Rendering the global file useless.

    So, it seems that the world you are in takes precedence over your global files. I expect to be able to edit a global file and see that a user receives their prefix/permissions right away. I do not want to copy and paste my changes to the global files into each of my worlds, and my automatic donation system certainly doesn't want to do that ;). This would make global files useless.

    A quick fix for this until you have an update would be to mirror the global files to each of the worlds in the mirrors.yml, but I'm not sure this is possible. What can we type in the mirrors for the location of our global files in mirrors.yml? I would assume it was something along the lines of world *:world, but I'm not sure how all of that works (could even be bpermissions:world, or it might not be possible yet). I'll look for some documentation on this and play around with things until somebody can enlighten me :).
  6. Offline


    I have a problem regarding bPermissions too but i have no clue how to post a new thread i would greatly appreciate help. Whenever i start my server i get a message saying file load error or something and my prefixes dont show up i may have it in the wrong spot but i dont think so if someone could fix them i would be very greatful. Tracks.yml http://pastebin.com/bkP5sY2r . world.yml http://pastebin.com/ctKh3U6Z . groups.yml http://pastebin.com/qqXBgWCH . users.yml http://pastebin.com/nWnDNtD0 . Thanks
  7. Offline


    I have similar problems like fluxty.
    Global-userfile is useless, cause bPermissions create the user in world-userfile and puts the user in the defaultgroup in the world-userfile, if the user was not in the world-userfile already.
    But when the user has to be created and set up in _all_ world-userfiles, the global-userfile is useless.

    I would like to manage all users in global-userfile.
    I have builder as defaultgroup and builder2 inherits builder and adds "essentials.fly" to builder2.

    But for my survival world I did not want to have builder2's flying around.
    So I set up a group "builder2" with permission "^essentials.fly" in my survival-world-groupfile.
    The survival-world-userfile is empty. Only default:builder.

    Problem is now, when a builder2 joins the survival world first time, bPermission creates a user entry in "survival-world-userfile" and puts this user into the defaultgroup "builder" in "survival-world-userfile".

    Now this user is "builder2" in global-userfile and "builder" in "survival-world-userfile".
    Problem is "builder2" in "survival-world-groupfile" should remove the "essentials.fly" permission. But as it seems this does not happen, cause the user is "builder" in "survival-world-userfile".

    Logical workaround should be:
    a) copy global-userfile to all world-userfiles or
    b) empty global-userfile and have all users set up in _each_ world-userfile.

    In both version I have to manage multiple-userfiles when a new user comes in.
    And I wanted to use a global-userfile that I only have ONE place where I can manage ALL users.

    Related problem: /world * selects the global userfile, but that doesn't help. There is no /world "all" or similar, so that I can manage a user in all world-userfiles with one command.
    However, new shorthand commands could do that. Yes.

    Best Regards
  8. Offline


    In my experience, if I type /world pvp instead of /world * when selecting a world, it updates the global files without a glitch. I tried the method where you type /u has <perm> in all the worlds (including nether) and it seems to work.

    of course, I went to try this with real perms instead of foo.* , but then it went haywire and deleted everything but prefixes when i switched from /w pvp to /w * so DON'T DO THIS!!! (thats why they have backups )
  9. Offline


    Good way to necro a thread from 6 months ago :p.
    This isn't in regard to checking permissions, it's that the global perm file isn't being enforced on blank world perm files. I've found my replacement for bPerms in the mean time: zPermissions.
Thread Status:
Not open for further replies.

Share This Page