You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 12, 2021. It is now read-only.
Thanks for the suggestion. This is a limitation with how CanCan's DSL works since the permissions are freely defined in Ruby. I don't know of a way to convert that logic to SQL.
In many cases I think the simplicity of CanCan's DSL makes this trade off worth it, but if you have a lot of complex read permission logic in your app, I'd suggest going with Declarative Authorization.
I'm opening this back up because I have some ideas on how to add this. What if the can method optionally accepted a conditions hash as the last parameter instead of a block? For example.
can :read, Article, :user_id => user.id
In this case the user only has permission to read articles which he owns. The conditions can be retrieved for using in an Active Record query or any other ORM one is using.
The conditions method would blow up with an exception if there's ever a block used in the Article :read permissions because then there's no way for it to deconstruct that into a simple conditions hash.
I think this DSL is nicer than the block for other simple situations as well. You don't have to check for nil.
More a suggestion than an issue but it would be cool if cancan can do query rewriting like declarative_auth
http://github.com/stffn/declarative_authorization/
like
Employee.with_permissions_to(:read)
The text was updated successfully, but these errors were encountered: