Super Admin "rule" is misleading.

[4andrisbriedis]

Hello.

Documentation: https://spatie.be/index.php/docs/laravel-permission/v6/basic-usage/super-admin

If you want a "Super Admin" role to respond true to all permissions, without needing to assign all those permissions to a role, you can use Laravel's Gate::before() method.

Anyone reading this understands it simply - "super" is super. And "super" is access to everything. No exceptions. No extra hassle, as it should be. But it is not!

"auth()->user()->hasAnyPermission(['myPermission'])" return false for user with "super" role. It shouldn't be like that. Why is it necessary to make additional checks in the code separately for "super"? Where is the logic hidden here? I don't see it.

Please, either supplement the documentation and correctly indicate that it is not "super" and how to solve this problem, or, much more correctly, actually make "super" super, as it should be.

p.s.
As I see, I'm not the only one who perceives it this way after searching on google. And this problem has been relevant for several years. But there is no additional documentation, nor has "super" become a real super administrator. Please explain in the documentation why you follow such a policy for the role that must be able to reach everything. Whose goal is to reach everything.

[drbyte]

I'm not sure I understand where the confusion is. Perhaps this may clarify:

If you create a role, and want that role to be "super", then you simply have to define the logic that "makes" it "super".
The most prolific way to make a "role" be "super" is to use Laravel's Gate::before and have it return true to any Gate authorization/permission check (ie: can(), canAny(), cannot(), etc).
That is the method which this package has adopted to support the "super" feature, and provides the most consistency and compatibility with all other Laravel auth operations.

If you wish to skip Laravel's way of checking permissions, and very specifically use only this package's hasPermissionTo(), then you will have to add other checks to incorporate a "super" feature.
There are currently no plans to have this package intercept its own functionality in order to do what Laravel's Gate already does.

[drbyte]

I've added a note to the docs (/docs/ directory of the repo) to add clarification. It will be reflected on the live docs site after the next build/push which will happen sometime in the next week or so.

[4andrisbriedis]

I will try to explain how I see it.

First and foremost: Super admin must have access to everything. Point. There is nothing to discuss here. Otherwise, he is not a Super admin. If he has limitations, he is not a Super Admin. And that's ok. But it's not Super admin then. Simply. Logically.

This package is used by many. Experienced and inexperienced programmers. The essence of using packages is to simplify these functions for those who do not want or do not know how to create such things independently. And simple to apply. And that's normal.
An experienced programmer will search for "laravel type/policy", "spatie type/policy" in case of a problem, and sooner or later they will solve the problem. At least with crutches.

A less experienced programmer will get stuck. For a long time. Maybe even refuse the package and look for something else. Which one is the winner?

"Politics" for politics, but simple logic is still the best policy. "Want a super role? Create it, put this code in boot() and {"Super Admin" role to respond true to all permissions"}". Where is easier to say? right? But no. It doesn't work. boot() returns true (long before the entitlement check). But "auth()->user()->hasAnyPermission(['myPermission'])" returns false. It is not "true to all permissions". It's not my function that doesn't return true. It is a package function that returns false when checking "permission/s" instead of "true to all permissions".

I am no stranger to php. But I also could not find why super is not super long enough. It was only when I found a similar "pain" on Google that the thoughts of where the problem was started to appear. But the problem could not have been if super was super, which answers "true" to all "permission" checks, as written in the documentation.

It is not a problem that the developers have thought differently. The problem is that it is not clearly written. More precisely, the opposite is clearly written.
If it is written in the documentation, simply written, "this can do that", "this must be done" and "we use the term ABC as a.b.c instead of ABC", then there would be no problems. We, I can live with it.

In any case, thanks to the developers. Greatly simplifies the application of rights.

p.s.
If we allowed different "companies" to impose their policies (unfortunately, many do), even the Internet would be for a fee, as a minimum. Ask "philanthropist" Bill how he saw it.

p.p.s.
Sorry for being so long, but I can't see the logic behind super not super.