I'm frustrated and disappointed. I need strong support for group management. Specifically: I need, at a bare minimum, to be able to create and remove groups dynamically, add and remove players from groups dynamically, determine which groups a player is a member of, an which players a group contains. Some bullets: Groups as a tertiary usage of permission nodes meets the bare minimum need. Dynamically must be interpreted as meaning, "while a plug-in is operating, and without requiring permissions to be reloaded." If there is a programmatic way to reload permissions using only the Bukkit API, this would be sufficient. I absolutely cannot afford to create a dependency on an external plug-in that a server operator may choose not to use, so this functionality must be supported through the Bukkit API interfaces, even if it is implemented by the permission attachment (?). Permissions are useless to me without at least this much.
I guess you would need to either make the extra plugins soft dependencies and create the parent permission dynamically once the core loaded, or start creating the permission as soon as you load but then have an API call that the other plugins can add to expand on the permission. In the latter case though, I'm not sure how you'd complete the actual process of creating the permission once all possible plugins have loaded, since permissions are immutable. Actually, I guess I also have this in General with kit permissions... I think you'd just have to leave the dangling permissions there for now, but having a delete permission option does sound like a good idea. I think you'll need to gather all the various nodes that people use into a central place and, once the config is loaded, sort through them and build the permission hierarchy dynamically. Yeah, plugin authors can break expectations with this. They could even create a permissions node called "fred of the jungle$$123" if they wanted to. Trying to add a permission that already exists raises an exception. I imagine this would apply even for permissions defined in the plugin.yml.
ok im just having difficulties at the moment. I dont understand what the format is for permissions.yml or are we to use the superperms and bridge to do our permissions. Or can i stick with what i know (group manager) it may not be the best but there are going to be some learning curves for me here if i cant understand the way its all meant to be put together. If you can just give me a format for one thing that i could work off of.
Hmm... I see how I can loop through the custom permissions from my config and create a ".*" permission node as the parent for each group of subnodes. It still seems so counter-intuitive that one could have: Code: permissions: doorman.*: description: Gives access to all doorman commands children: doorman.kick: true doorman.ban: true doorman.knock: true doorman.kick: description: Allows you to kick a user default: op doorman.ban: description: Allows you to ban a user default: op doorman.knock: description: Knocks on the door! default: true doorman.denied: description: Prevents this user from entering the door And now the giving doorman.* does not give doorman.denied? Seems very prone to developer error as well if they forgot to add a particular node as a child. If conflicting permissions result in an exception for the latter one I don't see the problem with allowing doorman.* to provide all subnodes (eg. doorman.blah, doorman.1.2.3, etc) as no other plugin can register/create the "doorman" permission.
Hmm how about with world guard? For Example: Code: permissions: worldguard.region.*: description: Gives access to all worldguard commands children: worldguard.region.flag.own.*: true [can that work? or you have to write out all the regions they own?] worldguard.region.flag.flags.*.owner.*: true [Would the 1st '*' work or I would have to right all the flags out?] worldguard.region.setparent.own.*: true [Is this able to work or am I going having to wait for a fix of some sort?] world....etc.... I have other plugins that use that type of node would it work or is that something that I would have to wait for the plugin creator to work on? I do not have this implemented yet, still using bukkit #953. ps: if I made no sense I sorry its 4:09am very tired atm lol EDIT: Hmm another concern, well question pop to my head, when you are adding multi-worlds into the Mix for the permission part is that for the default world and the other worlds you add in the WORLDS: section or do you add all worlds in the worlds section n in the permissions section you add nothing? Examples: Code: Guest: permissions: permissions.build: false essentials.geoip: true essentials.rules: true essentials.spawn: true lwc.blockinventory: true essentials.motd: true worlds: creative: essentials.geoip: true essentials.rules: true lwc.blockinventory: true essentials.motd: true OR Code: Guest: permissions: permissions.build: false worlds: creative: essentials.geoip: true essentials.rules: true lwc.blockinventory: true essentials.motd: true survival: essentials.geoip: true essentials.rules: true lwc.blockinventory: true essentials.motd: true I know they both have same perms but others groups does not, have over 20 groups on our server. Little confused on this part
I think you'll use a hash table to store the calculated permissions. So if you ask for foo.permission, you'll first look at calculated_permissions["foo.permission"], then failing that look at defined_permissions["foo.permission"] and parent_permissions["foo.permission"] (e.g. finding foo.* is (one of) the parent(s)) and recurse. If the permission was calculated using defined permissions/parent dependencies, you'll store it in calculated_permissions. If a plugin adds "foo.permission" later, you can delete calculated_permissions["foo.permission"] and delete it, but if somebody adds "foo.permissiongroup" being a parent of "foo.permission", you'd have to clear calculated_permissions or do a complete hash walk, which would even cost more. Doing this automatically would be insane. I'd suggest allowing a direct definition to override a cached result (as described above) and to provide a "/permissions flush [cache|parents|all]" command to clear the cache, so e.g. a plugin having reloaded it's permissions file could update the server.
I also like the ease of *, especially withPlugings that create that hierarchy on the fly for every block/item type etc. How can you specify to allow all blocktypes and disallow a small list? How it is setup now, with updates on blocks, either the admin needs to add those block permissions or the plugin author needs to publish a new version, even if the code didn't change at all, just to make sure ".*" includes the new block IDs. The thing is... if this really stays that way, we just have to say goodbye to the .* semantic. For not confusing anyone it's best to educate everyone that .* doesn't exist with the current system anymore and if you need groups_of_permissions/child-permissions, just give them an appropriate name and don't use * Like: Code: permissions: doorman.sets.moderator: description: Gives access to moderator doorman commands children: doorman.knock: true doorman.denied: true doorman.sets.admin: description: Gives access to admin doorman commands children: doorman.kick: true doorman.ban: true doorman.kick: description: Allows you to kick a user default: op doorman.ban: description: Allows you to ban a user default: op doorman.knock: description: Knocks on the door! default: true doorman.denied: description: Prevents this user from entering the door Or am I overlooking something here? I didn't check the API yet, but if the implementing permission class is asked every time when .has() is called, what keeps it from implementing the * semantics?
I'm disappointed that the same approach used for custom map generators (provide just an interface and a manager and let the plugin dev worry about backend storage/permission resolving/implementation) wasn't used and instead what seems a slightly clunky frontend was made instead where we lose key benefits of the current system (metadata storage for groups and wildcard resolving). I just don't see the benefits outweighing the costs here. From what I can tell, a permission plugin must specify All allowed nodes, instead of being able to calculate them on the fly and then cache the result. I can't see the sense in forcing us to cache the result inside of the bukkit API, when it could just as easily have passed the query to a plugin implmenting a permissions interface. I also have to raise a query, I see no confirmation of whether this interface supports multiworld. on some servers this is an absolute must.
It supports Multiworld in the way that you can change the attached permissions as soon as a player goes to another world.
Could a method be added to the API. Player[] getAllowed(String permission); This would return all players who have that permission. getAllowed("group.<group name>") could be the unofficial official group node. A plugin could easily scan though all players anyway, so no big deal. The only reason to have the method (other than convenience) is if there was some internal node -> Player lookup. Also, it would be nice to have non-boolean permissions. Integer getInteger(String permission) Integer getString(String permission) A permission could in theory store a string and an int. This would allow things like chat prefixes and setting timeouts and other limits for players.
Yep, I mean why define the . and the * as “special permission name characters” which seperates a permissions. Actually, you also could use only the asterisk as a special character as there is no difference between foo.bar.* and foobar*. If the plugin defines the permissions foo.bar.snafu and foo.bar.leet or foobarsnafu and foobarleet both are granted. The first one is only better to read. But as far as I get this right, a permission plugin still can use the asterisk notation. I mean normally a plugin asks if the user has foo.bar.snafu permission. Only if a plugin defines a permission name with a asterisk this could be complicated. Isn't this also possible, with the “old” fashioned system? And these children things are acting like a shortcut? So a server admin either define doorman.* or the doorman.{kick,ban,knock} for the player with no difference? It is some kind of confusing, as the plugin developer could interfere with the permission configuration by the server admin. Fabian
So multiworld permissions have to be reloaded everytime someone Teleport's? Where is the performance bonus in that? Also, am I right in thinking that permissions are duplicated across people in the same "groups".
Don't discount readability... also, with "foobar*" what happens if the player uses "fooba*"? With the dots "star.gate.open" and "stargate.open" are two completely different branches, without the dots they are the same. I see it similarly to folder names - eg. "cprogramfilesjavabinstuffhelptxt" isn't very readable or practical (is the folder "javabinstuff" or "java/binstuff" or "java/bin/stuff"?). No, this is not possible - "doorman.*" would never match "fred.kick" in the old system.
This depends on the plugin developer. At the moment the name could be everything and no character has a special meaning. Now previously there was a special meaning for the asterisk, but the dot itself hasn't a special meaning. It was only there to make it more readable. And don't get me wrong: I don't want to say that the dot notation is senseless and the additional readability isn't very much. I only wanted to say, that maybe it could be useful, if the asterisk get a special meaning. But they don't need to implement a special meaning for the period, as this is simply a character in the name. It is simply, why do you need a special meaning for the period. It is there only for readability and don't change the behavior of the permissions. “star.gate.open” and “stargate.open” are only different “branches” because the name is different. “foo bar snafu” and “foobar snafu” are also different branches without any period Ehm, I only wanted to say, that also with the old system it is possible to define a permission node “fred of the jungle$$123”. Fabian
Hmm, I got a question that wasn't really made clear: If I update to CB1000, can I still use the permissions plugin and ignore the built in permissions? I updated to permissions 3.1.6 recently and it works really well... we have about 35 different groups and a huge users file too sorting all our users to various groups and multigroups.. I REALLY don't want to have to change all that to a new system if I can help it... Until I know I can keep the old Permissions plugin I think I'll stick with 953, as buggy as it may be...
Another question... if the user gets assigned doorman.*, can I ask if he has doorman.*? If this works, can I also ask fro doorman.* if I assign kick,ban,knock separately? doorman.*: description: Gives access to all doorman commands children: doorman.kick: true doorman.ban: true doorman.knock: true
You can keep your permissions as long as a dev updates it to work on the build you're using. It will take quite some time till permissions plugin use this new system and then it will be marked so.
Groups will be handled by plugins if you need them. Bukkit isn't providing a complehensive permissions management system like you're used to withthe plugins - it's more like what Register does for economy plugins - it's just a common interface. You can define simple permissions in your server's permissions.yml if you only need simple stuff - perhaps you only use op/not op. Who needs groups if you have 5 users on a private server? This is meant to keep it simple for those who don't need Enterprise-level permissions. For those of us who DO want groups, wildcards, promotions, in-game commands, etc. these will be provided by plugins. Basically, Permissions "4.0" will, instead of having plugins hook into it's own interfaces, itself hook into Bukkit and report the permissions users should have (based on their group, etc). Then, plugins can hook into Bukkit's interface and check if expected nodes are set. This way, permissions are extensible as well. Want WorldGuard to change users' permissions when they enter a specific zone? Just config it. WorldGuard doesn't have to know what plugin you use for Permissions management (or if you don't use one at all!); it just knows the Bukkit interface. Don't like Permissions way of doing things? Maybe someone will resurrect GroupManager. Maybe someone will make an entirely new system. Hell, you could even have nodes defined in your permissions.yml based on classes in an RPG plugin like Heroes (each level-up auto-promotes you to the next node) and based on that your users automatically get access to more features/commands. Don't close your mind to this because Bukkit isn't going to manage your groups for you. Bukkit is doing what it was always designed to do, which is be as minimal an interface as possible and then GTFO of the way and let the community write plugins to handle the logistics how they want them handled. They're just providing a standardized framework here to ensure compatibility.
I have a couple questions: 1. are we still able to use rcjrrjcr's permissions plugin? Or did it break it? 2. If i did switch over to this, will it break all the permissions-supporting plugins, until they update? 3. Does this support chat prefixes and suffixes / colors, or will I still use iChat, or does this simply just not going to work out with this.
You have to remove the permissions if they're going from one world to another, and such. Other permission systems have to do this anyway, it doesn't magically update itself. There is no extra performance cost. Groups don't exist here. You can use this system without groups, they're only for servers who need more than "player" and "op". Wildcard permissions were a bad attempt at a fix to a problem which doesn't exist in this system. So no wildcards. No, it just adds whatever permissions has been specified, bukkit does the rest. Don't cache the result. Bukkit does it. It supports any type of permission criteria, unlike any other system. Permissions only on one world? Easy. Permissions only in one chunk? Simples. Permissions only for 30 seconds after teleporting from a specific area? One liner.
rcjrrjcr's Permissions is not broken and will continue to function. In fact, currently it is necessary until individual plugin authors convert their plugins over to Bukkit's API. Read some of my above posts as to why this is a Good Thing™. rcjrrcjr's Permissions will (if he chooses) continue to exist as a system to manage permissions for users; Bukkit has only taken over the function of allowing plugins to get/set permission nodes themselves. (Permissions would do lots of setting of nodes based on assigned groups, in-game commands, etc. while other plugins would usually do lots of getting of nodes to determine if users had permissions to do specific things). Prefix and Suffix (among other variables) are not supported in their current form - that is really more of a config issue anyway. Chat plugins will need to allow configuration of the prefixes and suffixes in their own config files (perhaps checking for a permission node you define in your permissions.yml and specify to the chat plugin in the config file). In other words - the only big change this brings about is how you configure things. In the end, you're not losing any functionality, you're actually gaining quite a bit more.
Let me make sure I'm understanding this correctly; once I create "myplugin.*", either runtime or in plugin.yml (not bukkit.yml, right?), I can't add or remove children from it (those children must be known at the time permissions are loaded) and I cannot delete it (in order to reinstantiate it with modified children). Is this correct?
Correct. If you find yourself dynamically adding lots of permissions which you need to add to .*, consider just making .* an override for them (check .*, then check .x)
You could stick with Group Manager, but I wouldn't recommend it unless someone has picked it up and is continuing to develop it. You don't have to switch to SpaceManiac's plugin if you don't want to; you can use whatever permissions plugin you want as long as it (eventually) supports built-in Bukkit superperms. It does seem counter-intuitive at first glance, but note that doorman.denied is actually intended as an inverse permission. That is, instead of giving you permission to do something, it revoke the ability to do so. So, with that in mind, excluding it from doorman.* (and, indeed, explicitly setting it to false in such) makes sense. This is up to worldguard to define. If I were the developer of WorldGuard, I would probably try to define it so that you can use the internal asterisk like that. I don't really know what WorldGuard flags are, though, so I'm not sure if that would be possible. It certainly wouldn't be possible in the plugin.yml; he'd have to define it programmatically upon loading. @SpaceManiac – Correct me if I'm wrong, but... I think you only need to specify the permissions that are not the same in every world under the worlds heading. So, in your posted example, you don't actually need a worlds heading because they're all the same, but if (for example) you wanted them to only have lwc.blockinventory in the creative world and not in any other, you could do something like this: Code: Guest: permissions: permissions.build: false essentials.geoip: true essentials.rules: true essentials.spawn: true lwc.blockinventory: false essentials.motd: true worlds: creative: lwc.blockinventory: true While having a flush command is a nice idea, I think it'd be better as an API call than a default command. Not if the plugin author did it correctly. I have a permission that has one sub-node for every item. When the plugin is loaded, I loop through all the values of the Material class and add the corresponding permission to the .* permission. This way, if new blocks or items are added, it will automatically expand to include them as soon as Bukkit adds them to the Material enum (which I think is one of the first things they do after updating anyway). You don't want to define permissions like this in your plugin.yml; that would just be insane. That's true, it is possible with the old system. There should be no problem with sticking to Permissions. Presumably it'll eventually be updated so that it works with plugins that rely on Bukkit's permissions system, but even before it does that there's no reason why it shouldn't continue to work with plugins that explicitly support it.
Hey Dinner bone can you explain to me this: do we still need a permissions plugin? And can you help me write the code for the permissions.yml? Basically I am the server owner so naturally I'm the admin and have access to all commands my minecraft name is: BattleGroundxx And my friend is part of another group (moderator) and has access to all default commands (build, destroy etc.) His minecraft name is: mittydoug And i know that certain plugins have permissions and since this is a private server the admin and moderator groups have access to all commands that are required by plugins and i am going to install PermissionsBukkit v1.0 - Official Default Groups Plugin [1000] So all I ask is you write the code for the permissions.yml and the plugin above because im not so computer savy and 1 more thing the moderator group does not have access to these commands (basically the ones required by PermissionsBukkit) anyways these are the command the moderator group has no access to: PermissionsBukkit uses the command /permissions, with aliases /perms and /perm. /permissions reload - reload the configuration from disk. /permissions check <node> [player] - check if a player or the sender has a permission (any plugin). /permissions info <node> - prints information on a specific permission. /permissions dump [player] [page] - prints info about a player's (or the sender's) permissions. /permissions group - list group-related commands. /permissions group list - list all groups. /permissions group players <group> - list players in a group. /permissions group setperm <group> <[world:]node> [true|false] - set a permission on a group. /permissions group unsetperm <group> <[world:]node> - unset a permission on a group. /permissions player - list player-related commands. /permissions player groups <player> - list groups a player is in. /permissions player setgroup <player> <group,...> - set a player to be in only the given groups. /permissions player addgroup <player> <group> - add a player to a group. /permissions player removegroup <player> <group> - remove a player from a group. /permissions player setperm <player> <[world:]node> [true|false] - set a permission on a player. /permissions player unsetperm <player> <[world:]node> - unset a permission on a player. If you can do all this i would VERY VERY VERY VERY much appreciate it! The plugins I am currently running are: AutoRepair BananaChunk ChopTree ClayGen FastObby HeroicDeath HomeSweetHome IntelliDoors ObsidianFlow SpongeRestore Stackable Stargate TorchLight Again all groups/users have access to the commands required by plugins! Thank you very much if you can write the code for permissions.yml and the PermissionsBukkit That would be so helpful I know this is a Large request but again I am not computer savy with java. If you can complete this for me I that would be greatly appreciated. Thank You!
That long list of commands you posted - that's for setting the permissions yourself. You don't need to touch a config file. You just need to know what nodes the plugins use. Also - none of those plugins recognize the new Bukkit system yet (they need to be updated to use it). Keep using your normal permissions system for now - Dinnerbone probably does not have time to go around writing config files for everyone.
