With the advent of the integrated Bukkit permissions, there have been a few new permission-handling plugins released. Of all of these, nothing is a simple, effective and efficient as the old GroupManager, which was bundled with the essentials package. My request is a system that is either based on or very similar to the old GroupManager system, with the same commands, same Yaml set up, folder layout etc, that supports bukkit-integrated persmissions, as well as the backwards compatibility for the old 2.0.x permissions system. The only reason I am requesting this is that more and more frequently plugins are only supporting the integrated bukkitperms. It seems I have to leave the old GroupManager to , but it would be so wonderful to have this! Anyone who has used GroupManager in the past would understand.
bPermissions doesn't support different default groups on a per world basis. I am trying to move to Permissions EX seeing as they support bukkit permissions, and have far better multiworld support. However, the bugs are driving me insane, and after hours of messing with which group is default where and when, I still cannot get this to work. Group manager was so simple in that each world had its own user file and groups file. It's the multi-world support that's really letting me down when it comes to bukkitperms.
You don't have to use Bukkit Permissions yet if you don't want. People are not entirely happy with how it currently is. (But most of them still like the idea of a Permissions API.) Read more here.
I agree some what. Imo, Super Perms has a far way to go before being a standard. Permissions was setup quite well, yes there are some nicks here and there that should be changed, but the overall project was setup how permissions should behave imo. There was already something that made logical sense. Why take that very aspect and turn it into something completely different from what users have already grown to know? I just think SuperPerms needs to be incorporated into the environment which was already laid down.
bPermissions doesn't support different default groupnames on a per world basis. Noone sees them apart from you. Is that really such an issue? bPermissions has support for this plugins/bPermissions/players/worldname.yml - the players config file plugins/bPermissions/groups/worldname.yml - the groups config file How is that any different WHATSOEVER to what groupmanager used to do? All I've done is make it not break if you don't setup those groups.
@codename_B I never said bPermissions didn't have good multiworld support. It just doesn't support different default groups. The way I see it: When players join, they enter world "creative", as default group "builder". There they can do whatever. Then, if they like, they can travel to world Survival, and then default across to group "Survivor". ....and when a player is defined to a group using a command, it is on a per-world basis, and promotion happens on a per-world basis too, so that when builders become advanced builders, or moderators or admins, when they travel across to world "survival", they still default back to "Survivor" group. From what I can tell, bPermissions has a config file: config.yml - any player who does not have a group specified will default to the group specified here. This is excellent, but it means that whatever world you're on, you'll always default to the same group. So if people joined my vanilla survival world, they'd default as Builders, because that is what they join as on the creative world.
Because I use Groupmanager too since the first release, I request a Superperms-GM too. Would be awsome, I like it, just the perfect permissions Plugin (jep, I'm testing/tested the others on my testserver) I like the Multiworld System of gm... Mirroring the configs in the main config, or a seperate group cfg for each world.
Why not have the "default" permissions set as the default: group for each world? There is really no need to have a different "name" for the group - you may as well call the group "bobcats" and it would make no difference. No other plugin ever sees that group. I am going to be adding default groups for different worlds, but I really don't see the point. Code: default: - give.item - bPermissions.build - bInfo.default Code: default: - bPermissions.build - bInfo.default Is there really that much of a difference being able to change the name of "default" per world that it's an absolutely necessary future - and will stop people using the plugin because of it?
What @Jobsti said about mirroring permissions across world in the config is great. @codename_B I assume the - bInfo.default makes the group that has that permission node a default group?.. and that it could be applied to any group, so long as there is only one group with that permission? I'll test that now, and if that's the case then what I have put below here is probably useless information.. In case you don't read on, the last suggestion is a world-inheritance - one world copies all the groups, users, and their permissions from another world. Also, I'm curious as to whether bPermissions has user-specific permissions. I don't see a command or config for it on the OP of the bPerm page ----------------------------------------------------- basically I just don't want people running around with a [default] tag. Here, the old permissions system works rather well. See Spoiler; Spoiler (Move your mouse to the spoiler area to reveal the content) Show Spoiler Hide Spoiler under a world config file, eg. groups/creative.yml (world name = creative); groups: builder: - permission.build - permission.give - permission.changetime default: true admin: - "*" default: false then under a different world config, lets say survival.yml groups: survivor: - permission.build default: true admin - "*" default: false ###so now if a player joins the world Creative, they're default as Builder, and if they change worlds to the Survival world, they're default across to Survivor; and when an Admin alters their group, its always per-world in the users.yml file As for the config file, then a mirroring system is perfect. Lets say we had two survival worlds - Survival and Challenge in the config.yml file : world: mirror: Survival: - Challenge so then all permissions from world survival (including users and which group they are in), are copied directly across to the other world. This is basically world inheritance. One world inherits all the users and groups and their permissions from another.
that's the forum's fault =.= not mine. I'll send you a file with the proper formatting if you like. Also, does bPermissions allow user-specific permission nodes? Edit: nevermind I see that it doesnt :s I'll have to keep searching. PermissionsEX has been the closest to what I need so far, but the default groups on that are stuffed at the moment as well =s. Back to group manager, I guess. Otherwise I'll have to ditch multiworlds. The request is still there, though. GroupManager is pretty much perfect - it does everything, and still works like a charm. If only it supported SuperPerms.
@xsolar66 - just a couple more questions before I give up and concede that you're beyond enlightenment: What's wrong with this? world1.yml Code: default: - permissions.set.1 - essentials.set.1 world2.yml Code: default: - permissions.set.2 - essentials.set.2 Hint: the names are the same - the permission sets are different - noone else sees the names but you - what's the issue? Also - on that note - why are user specific permissions so important? If you need to add individual permissions to a user - what's stopping you from creating their own group and setting up their permissions that way? That is 100% supported and by far the preferred way to do things - adding support for per-user permission nodes would be way overcomplicating things. Also - I do believe you're just being lazy because you don't want to update your GroupManager config - news for you - you would have to update it. SuperPerms does not support the '*' node. ALSO - I still haven't heard a valid argument against bPermissions other than it doesn't support different default groups per world - but it DOES support different default permissions sets per world. Are you such a person as that you won't be able to read the name of the file and immediately know if its your creative or your build world? You need the group to explicitly be called "builder" on one world and "creative" on another? Fair enough if this is the case - and as such I can see why my argument isn't getting through. Whats the real difference here though? Code: default: - permissions.set.1 Code: builder: - permissions.set.1 and for world 2 Code: default: - permissions.set.2 Code: creative: - permissions.set.2 Seeing them compared side by side should convince you of the validity of my argument - if not - then I wish you well with GroupManager as plugins you use slowly stop working, one by one - your refusal to upgrade is ridiculous.
You're right, of course. This does, however, mess up the prefixes a bit (using bInfo/chat), and the tag in front of players names to say which group they're in. I use this to know who's where. If people are playing creative, they'd have a [builder] tag, but if they're on the other survival world, the tag would be [survivor] (player). The request for user-based permissions is to do with there being over 20 different users all under one group - "builders", and the majority of these users have separate permission nodes that I hand out from time to time as an administrator. Things like the ability to use a super pickaxe if they build a nice pixel art, or to jump higher, or if I liked their house they built, I'll let them spawn a cow, by simply adding the node - /manuaddp *user* *node*. Ok maybe, maybe I am lazy, but it feels silly to try and create 20 different groups, one for each member on the server, and add permissions to them, when rather I could, in a single command, add a node to a player each time i want to reward someone with an ability from the many plugins I use. So, yes you're right, I could have one group called "Default", and have different sets of permissions - one for creative, and one for survival, that apply depending which world they're in. . but then I would never be able to tell which world users are on when they chat and have to use some command like /where or /list to find out where people are at. I'm not worried about the * node, (although its annoying that it's not there, haha. more work.). I've already attempted setting up my permissions file to work with bPermissions, and I finished the groups and was ready to start on the users when I saw they didn't have specific nodes for users. . so i thought, well that's odd. To conclude - I am not refusing to upgrade, but merely insisting on upgrading without taking away from what I have already spent months on, with all the permissions and groups and user nodes. I think, that if bPerms was to have that bInfo.default node mentioned earlier (was this implemented?), or some sort of default:true node for a group, along with something like: playername: groupname1 - node.node playername4: groupname2 - node.node Not to mention some sort of world-mirroring, or inheritance. world1 has same permissions/groups/users as world2. ...then it would indeed be the superior superperms plugin. So there you have it Three requests. First because I'm lazy and dont want to create a large number of groups, (one for each user, =.=). Second request because I like to think that I can keep my prefixes intact, and know who is where. And the last request so that everything I set on one creative world I don't have to plug in to another creative world.
I like to keep my config files as simple as possible - if I had all that - you would be complaining that it's too complicated. Anyway, I'm done here - keep using GroupManager. Yes you would. Code: default: - bInfo.creative Code: default: - bInfo.builder
He's wants to stick with what works, stubborn, as they say you can't fix something that isn't broken. But don't worry he'll be forced to upgrade some day.
Of course I want to stick with what works. Because it works. Well, Almost- Apart from these new Superpermissions. And the problem I am having is that bPermissions and BukkitPermissions don't have the same functioning world mirroring, prefix/suffix/default group control/* for all permissions that group manager did. I don't mind upgrading; but I don't want to downgrade. Thus my request remains intact - if someone knows how to or is capable of adding superperms to the original groupmanager interface.. The problem is that there was nothing WRONG with group manager, apart from the lack of super permissions!
PermissionsEX seemed to get prefix/suffix working ok; and I would be using that at the moment if only the default groups weren't broken
I too would love implementation of superperms into groupmanager. I've been using GM since release and have had no issues from it, unlike all other permissions based plugins I've set up (missing features, broken commands, etc.).
