Break it Down - "SuperPerms"

After the debacle about the resurrection of Permissions and seeing so many people speaking in an uninformed manner about "SuperPerms" I felt I should break down the "SuperPerms" system for anyone to understand. Granted, the Bukkit team has already done this (and for that matter, many notable developers have done this), but apparently the message hasn't reached everyone.

People seem to confuse two things above all -- "SuperPerms" and PermissionsBukkit.

Starting with "SuperPerms" as it is what this entire post builds on...

"SuperPerms" is a part of the Bukkit plugin API. It is build right into the API so that developers like us just have to use one simple line of code to check if a player has permission for something -- a boolean (true or false) value for the given permission key. That is absolutely all a permission is anyway. "Can I come in? No, you don't have permission." It's either yes or no. That is the literal definition of a permission. It really is fortunate that this API is so incredibly easy for us developers to use, and even more fortunate that it is a part of Bukkit now rather than an individual plugin. The reason this is so fortunate is because we don't have to worry at all about what plugin you use to handle permissions, it's always the same line of code to do a permissions check! Speaking of permissions plugins, now we come to the PermissionsBukkit part of the discussion...

PermissionsBukkit is a plugin -- entirely separate from Bukkit. It is a bare bones permissions plugin that provides only what is crucial -- groups and user permissions, as well as a simple command system. Personally, I found it incredibly easy to set up and the commands very intuitive to use, but others have not had this same fare, apparently. This created a wave of resistance to "SuperPerms" very unfairly as uninformed users blamed "SuperPerms" for the supposed faults of PermissionsBukkit. This wave of resistance eventually created the ill-fated attempt at reviving Permissions, where there was much conflict and insulting. One of the most oft-claimed things in that thread was that Permissions 4.0 (or whatever its name ended up being) would be a "SuperPerms" alternative, which is downright silly. "SuperPerms" was created so there would be no alternatives! That makes things much more difficult on us developers! People there seemingly enjoyed the idea of reviving the old Permissions because it was easier to setup, but that is not a fault of "SuperPerms", that is something to take up with the plugin you are using for permissions! Sure, an attempt to make a "SuperPerms" manager that allows deprecated Permissions users to simply drop their file in would be a valiant effort, so long as it uses "SuperPerms". Likewise, said plugin could offer support for prefix/suffix and what not, just so long as it uses "SuperPerms"! "SuperPerms" is not responsible for these things though, and it never should be.

This has all been said before, over and over, but I would like my turn to try and explain it. If you still have a complaint about "SuperPerms" please, by all means post here, and we will discuss in a civilized manner.

tl;dr: "SuperPerms" does not affect you (AT ALL), server operator. The plugin you choose for your permissions does. Just be sure you use a "SuperPerms" compliant plugin.

 

We never claimed our plugin as a replacement for SuperPerms. Anyways, PEX does everything we wanted to do with Permissions4 anyways.

 

So as a server operator I don't need to do anything with the "permissions.yml" that Bukkit comes with now? It's an optional feature or something?
I tried to understand the parent/child thing but Bukkit's description was too vague and didn't answer the above questions. I was looking for a more real life implication that showed the need for it, I understand how it helps developers. I just wanna know what I need to do with it.

I have no objections to switching(in fact I already did) I just wish it was smoother and gave better examples on how to switch from Permissions 2.x and 3.x. PEX so far has been the easiest for me, its almost identical to the Perm 2.7.4 YML configuration, which made it very easy to switch.

 

Its funny that there was so much opposition to Permissions 4 because PEX already exists, while PEX itself was once a copy of Permissions and simply had SuperPerms support first.

I think most people want a replacement for how you interact with SuperPerms and care very little for how it works in the backend. While I personally didnt see anything wrong with having Permissions with SuperPerms support, PEX does seem to be basically that.

 

permissions.yml allows you to create a custom permission. With children you can add various existing permissions to a person.

Lets say you want to make a custom node, and give the person two OP commands /ban, and /say.
You would write this in the permissions.yml

EG:

Code:

customop.numer1:
  children:
    - craftbukkit.command.ban: true
    - craftbukkit.command.say: true

To apply it to a person, you would have to have a permission manager.
(I personally recommend my plugin pailplus, for small/medium servers.)

 

I too think permissions bukkit is a fantastic plugin. Its very well done and does just what you need it to do. Just like the old permissions 2.7.4 which i was using up until the point i switched to permissions bukkit. I think the reason people dont like it is because it is different to setup from the old permissions system and people never like change. Once you get the hang of it. it is very simple to use. I even took the time to learn and setup permissionsEx but i still decided to go with permissions bukkit because it was simple and does everything i need it to do.

 

I think the resistance is from the way it got introduced and communicated.

At least the way I first read it was in the RB release notes, where it basically got dumped upon us, with only an explanation of how to use the basic system and a vague reference to the possibility of writing plugins that could help in administering.

I felt very lost as the only way to work with SuperPerms seemed to be by writing a permissions.yml that was much much more verbose than what I used before. I understand the Bukkit developers were proud of what they had done and wanted to share it with the world. But I think that had they communicated that the idea was that server admins should use a -then still to be developed- plugin, not just the core system. They might have said that, but it wasn't what I took home from the message. And with the primitive interface they did offer, it looked like a whole step back.

In the mean time I'm still on Permissions 3.1.6 as I have understood that I need to wait until a couple permission manager plugins have been developed and matured, but that was not what I initially got from the first announcement.

 

Yea, wait 1 or 2 weeks more, The next PEX update (1.14) will split the users and groups in two files, after that it will be 'matured' as far as I am concerned.

 

SuperPerms needs groups support - adding,removing,retrieving, etc - when that is done, I don't have to hook into any perms plugin any more

 

If you really need explicit groups support (ask yourself carefully if you do), then I'd suggest hooking Vault and not worry about hooking multiple plugins yourself.

 

What a 'Permissons 4' should be is a SuperPerms handler. Does all the same checks for permission, so no hooking into the plugin.
Group Based SuperPerms Handler. It needs to have a simple, but uniform means of configuration, easily editable groups and users. Oh and easy modification of player permissions in-game (ops only?).