Skip to content
This repository has been archived by the owner on Dec 12, 2021. It is now read-only.

Query rewriting #53

Closed
Skulli opened this issue Apr 11, 2010 · 3 comments
Closed

Query rewriting #53

Skulli opened this issue Apr 11, 2010 · 3 comments

Comments

@Skulli
Copy link

Skulli commented Apr 11, 2010

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
Copy link
Owner

ryanb commented Apr 15, 2010

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
Copy link
Owner

ryanb commented Apr 15, 2010

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
Copy link
Owner

ryanb commented Apr 16, 2010

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

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants