[5.4] User Access to Abilities #19143
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Currently the
abilitiesare stored in theGateclass as a protected property. this PR adds a simple getter to return the defined abilities.the router has an identical method to access all the routes
Use Case
Currently if you set up some kind of Role/Permission ACL, you possibly store the Permissions and the Roles in the database. Chances are, the developer is still the only person who can CRUD the Permissions, because they still need to be used in authorization in the code. Then the layman are able to create the Roles and apply Permissions to them, and assign Roles to Users.
This would allow the programmer to skip storing the Permissions in the database, and instead simply define them on the Gate class. Then when Permissions are being applied to the Roles, we could use this method to access all the Permissions/abilities available.
If you don't need to have a web UI to define Permissions, the database becomes an unnecessary extra repository, because (often) the ServiceProvider is simply pulling the Permissions out of the database, and registering them into the Gate (the new repository). This PR will help eliminate that redundancy for projects that don't need the Permissions in a web UI.
I am currently testing out Spatie's awesome permissions package and that's where this idea came from.