Higher level roles do not seem to inherit from lower level roles about access-granted HOT 15 CLOSED

Hey, @parc64.

AG will only inherit from roles which also apply to the user.

So in your example if your user has a role set to admin, it won't match with role staff because it expects staff to be inside the role attribute.

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 role :admin

from access-granted.

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!

from access-granted.

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.

from access-granted.

The order is explained in the Readme here https://github.com/chaps-io/access-granted/blob/master/README.md#roles-in-order-of-importance

from access-granted.

awesome, thank you

from access-granted.

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?

from access-granted.

@rozhok you don't have to use roles. You can have one role for everything and do whatever check you like inside the can block.

from access-granted.

Oh really, missed last example, got it.

Okay, but it's not the best way to do that, isn't it?

from access-granted.

AG is made specifically to utilize roles, if you don't have roles then yes - it might not be the best way.

from access-granted.

I want roles, but I don't want inheritance. Is there way to avoid it?

from access-granted.

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 regular_role because that role is not matching the user at all (it would only match if the conditions were satisfied.

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.

from access-granted.

Oh, finally got it.

Thanks!

from access-granted.

Awesome, let me know if AG turned out to be useful 😄

from access-granted.

Everything works as excepted! Awesome. Using it in prod now.

from access-granted.

@rozhok fantastic! I do love hearing success stories :D

from access-granted.