-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
Recommendation for user groups #199
Comments
Hi, CASL perfectly works with domain models which have enough knowledge about themselves. CASL by itslef does not propose any population/loading logic, instead it expects that model has already everything inside. So, in your case you have 2 options:
So, then you can define your permissions like this: can('manage', 'Item', { groupId: user.groupId }) There is a proposal #160 which aims to add possibility to asynchronously resolve conditions but it has drawbacks and introduces complexity, so I don't know whether it will be implemented. |
Thanks for the response. For solution 1 that would only work for simpler use cases. If users are added/removed to/from groups frequently all items associated with those users would therefore also have to be updated every time. For solution 2, I'm not sure how you mean by that without an extra query to load the info from the groupId. Understandable adding promises isn't a clean solution, but it adds some flexibility which serves more complex use cases. |
create a method on repository level Eventually you will get the same result as with async conditions. + serializability. Another approach is to split abilities into several ones (you can group by models or by user roles). You can read this article for ruby for details https://medium.com/@coorasse/cancancan-that-scales-d4e526fced3d |
I chose to precache the given users groupmates. In my current use case that's sufficient since the groups are small and don't overlap. Thanks for the recommendations. |
Hi, great package! I'm trying to see if it can be integrated with graphql-shield for full api permissions.
I was wondering how one would implement permissions based on user grouping.
e.g a user can update an item created by another user in the same group.
If i have a groupId field on the user, and a createdBy field on the item, is there any way to populate the createdBy field when defining rule conditions for the item so i can determine if the active user is in the same group?
The text was updated successfully, but these errors were encountered: