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
Higher level roles do not seem to inherit from lower level roles #41
Comments
Hey, @parc64. AG will only inherit from roles which also apply to the user. So in your example if your user has a You should update the less important roles to also apply to admins, like this: role :staff, proc { |user| user.role == "staff" || user.role == "admin" } do this way admin will still have permissions granted by staff and will override them if there are any more important permissions in |
Hello @pokonski , Ok that makes sense. It would be nice to update the docs to show this example. The way the docs are now, it's difficult to understand if the gem is doing this behind the scenes or if the user needs to knit these together as your example shows. The docs also talk about the order of the roles in the access_policy.rb file, does the gem actually use the order for anything, or is that just a suggested good practice? Thanks! |
You are absolutely right, it isn't backed by an example, but only a short sentence. I will expand that :) And yes order is important because the first role which has a permission you are checking will stop further checks. So if a top role has 'cannot' defined for a permission, then Access Granted will not check the remaining roles. |
The order is explained in the Readme here https://github.com/chaps-io/access-granted/blob/master/README.md#roles-in-order-of-importance |
awesome, thank you |
Correct me if I'm wrong, but cant I set-up per-object permissions rather than roles and grant users access using something like bitmask? |
@rozhok you don't have to use roles. You can have one role for everything and do whatever check you like inside the |
Oh really, missed last example, got it. Okay, but it's not the best way to do that, isn't it? |
AG is made specifically to utilize roles, if you don't have roles then yes - it might not be the best way. |
I want roles, but I don't want inheritance. Is there way to avoid it? |
Yes, roles only inherit each other if they apply to the user. For example this policy: role :admin_role, proc { |user| user.role == :admin } do
(... some permissions here..)
end
role :regular_role, proc { |user| user.role == :regular } do
(...)
end for an admin user like this current_user.role #=> :admin will not inherit permissions from but If you'd like admins to inherit permissions from regular roles you could write a condition proc that matches admins, like this: role :admin_role, proc { |user| user.role == :admin } do
(... some permissions here..)
end
role :regular_role, proc { |user| user.role == :regular || user.role == :admin } do
(...)
end You have full control over how roles match, so you can construct any inheritance you want.... or no inheritance at all. I hope that example explains it this time. |
Oh, finally got it. Thanks! |
Awesome, let me know if AG turned out to be useful 😄 |
Everything works as excepted! Awesome. Using it in prod now. |
@rozhok fantastic! I do love hearing success stories :D |
Looking at this line from documentation at https://blog.chaps.io/2015/11/13/role-based-authorization-in-rails.html
Roles inherit from less important roles below them, but only from roles which apply to the given user. So we only need to add additional permissions on top of them. In this case, we will let members create posts and topics:
I have not been able to get this backward inheritance to work. I have something similar to this in my config.
However calling can? :view, Admin::DashboardController only returns true for the :staff role, and returns false for the higher level :admin role. Unless I uncomment the line in the :admin block.
The text was updated successfully, but these errors were encountered: