-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature - Ability to define different PermissionRegistrar #2623
Feature - Ability to define different PermissionRegistrar #2623
Conversation
- refactoring initialization - configuration isolation - strengthening of properties type declarations Allowed ability to use custom PermissionRegistrar for models and traits Allowed ability to use custom PermissionRegistrar in commands Allowed ability to use custom PermissionRegistrar for some methods in helpers Add tests cases for multischema and adapted some tests
Hi, any news about that? Thanks |
Still reviewing this. As you say, it's quite substantial. |
Hi, were you able to evaluate for a moment the underlying reasons for this PR? |
I believe I understand your objective, and am willing to consider it for future release. |
Would it still work if instead of calling |
I haven't tried, it could work but you need to try, you could do some tests so you can verify your thinking and check with the battery of tests. Thanks for the feedback. |
Dear contributor, because this pull request seems to be inactive for quite some time now, I've automatically closed it. If you feel this pull request deserves some attention from my human colleagues feel free to reopen it. |
Please consider the PR goal for the future. Thanks. |
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