Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Query rewriting #53

Closed
Skulli opened this Issue · 3 comments

2 participants

@Skulli

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)

@ryanb
Owner

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.

@ryanb
Owner

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.

Article.where(current_ability.conditions(:read, Article)) # => {:user_id => 123}

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.

What does everyone think?

@ryanb
Owner

adding conditions behavior to Ability#can and fetch with Ability#conditions - closed by baeef0b

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.