Feature - Ability to define different PermissionRegistrar #2623
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.
This PR replaces the PR #2618 refactors some code of the PermissionRegistrar and traits.
The goal is the possibility of being able to instantiate multiple PermissionRegistrar to isolate and use the library conveniently on multiple database at the same time (with possible different configurations without having to modify the runtime configuration).
Overview code changes :
The configuration is given (and isolated for the potentially extensible parts) as input during the initialization phase of the PermissionRegistrar.
It is also possible to overwrite the PermissionRegistrar used for models and traits, in this way you can use the library in a "straight" way on multiple schemes without having to change the configuration at runtime (see the battery of tests for greater clarity).
Currently I have not brought the entire configuration internally so as not to apply too many changes, but only the bare minimum that I have found currently implemented.
This approach is similar to the one also present in other libraries, for example see spatie/laravel-medialibrary (see provider and trait).
A possible breaking change is in the setPermissionClass and setRoleClass methods of the PermissionRegistrar where the global configuration is no longer updated as it is irrelevant.
I kept the binding of the contract optional although in my opinion it should be managed on the application side according to the business logic of the case).
I am aware that it is quite substantial as a PR and I probably missed something around because I don't know the entire library in depth, but I still wanted to propose it as a starting point for a future release (or in any case to consider its purpose).
Thanks