Adds support for rules at the attribute/method level

[phaedryx]

Allows you to add attribute-level rules, e.g.

can :read, User, :first_name
can :read, User, :last_name
cannot :read, User, :api_key

[phaedryx]

@coorasse something I would like you to weigh in on.

For the can? method Ryan added a third, attribute parameter here:
https://github.com/ryanb/cancan/blob/2.0/lib/cancan/ability.rb#L47

Unfortunately, in the main code base, he also added an extra_args parameter here:
ryanb/cancan@69f7a65?diff=unified#diff-d4e0a70d43eb4c389e623945f417d6e0R43
in response to this issue: ryanb/cancan#48

Which is part of the code base now. I thought it might be an undocumented or unused feature that could be replaced, but there are clearly tests for it here: https://github.com/CanCanCommunity/cancancan/blob/develop/spec/cancan/ability_spec.rb#L273

Because extra_args could be anything, the only way to reconcile is to change the can? method signature to def can?(action, subject, attribute, *extra_args) which would be a breaking change.

Thoughts?

[coorasse]

Good point. I also didn't remember of the extra_args feature honestly. 😄
I think is very useful and should be documented properly!

This brings me to a fixed point: we should preserve that feature.
Said that we have two options in front of us on how we could introduce the attributes feature: add a new parameter and break changes, add them to the extra_args.
in your example, if I use the extra_args I would end up with:

 can? :update, book, nil, [2, 3]

to have [2, 3] as extra args, which sucks.
Why don't we integrate the attributes directly in the extra_args?
e.g.

 can? :update, book, attribute: :title

this would not be a breaking change. what do you think?

[coorasse]

From my point of view we could also have a breaking change and be more open to future implementations. changing the syntax to:
can? :update, book, attribute: :title, extra_args: {...}

[CyborgMaster]

I'm very interested in having fields in our CanCan permissions and would love to see them as first class citizens.

@coorasse, I agree, having to pass nil as a third parameter to get to the extra args is annoying. This doesn't look very natural:

 can? :update, book, nil, [2, 3]

However, I'm not fond of having to write attributes: every time we check a permission. If I fold this into our project, I'll be doing that a ton and it feels a little clunky. It makes attributes feel tacked on and I see them as being just as important as action and subject.

What about going in between your two suggestions and making extra_args a named parameter and attributes an optional positional one. That way you could have calls like this:

 can? :update, book, extra_args: [2, 3]

or this:

 can? :update, book, [:title, :author], extra_args: [2, 3]

because extra_args is a named parameter and the attributes are optional, both would work. This way the three main parameters, action, subject, and attributes are all positional and the tack on, extra_args is named.

@coorasse, what do you think?
@phaedryx, would you be willing to go this way?

[phaedryx]

@CyborgMaster I like the suggestion. I'll explore some code around it.

I'm interested in this because I'm working on a GraphQL API and would love to be able to easily define attribute-level permissions in a simple, straightforward way.

@coorasse I like the symmetry of can :action, Subject, :attribute and can? :action, Subject, :attribute. Would your solution be to add attributes: to both?

[phaedryx]

@coorasse When I run the tests locally they all pass. I'm not sure how to solve the pg gem error.

[phaedryx]

I have removed the nils from the tests where they weren't needed and wrote a test to cover two instances when they are.

That is, the nil is only needed when you don't have attributes for a rule but you do have additional arguments that look like attributes, e.g. an array of symbols [:foo, :bar]. I expect this is a rare edge case.

[pedrocarmona]

I also need this PR. Thx @phaedryx 👍

[phaedryx]

Note: because of how I handled the initialize method of Rule, the change isn't as breaking as I initially thought it would be. The only incompatibility, like I mentioned above, is if you are passing a symbol or array of symbols as extra arguments (passing conditions works the same as before). The extra arguments functionality is barely remembered and undocumented, so I assume it is rarely used, let alone with an array of symbols. Adding a nil in this case doesn't seem like a big problem. All that said, I don't think I will add the attributes:.

[phaedryx]

This adds a permitted_attributes method. I imagine it will be used like this: params.require(:user).permit(*current_ability.permitted_attributes(:update, User))

[phaedryx]

I've been trying to make extra_args work as a named parameter and I've been having some difficulty. The primary problem is how mix conditions hashes without {} (which is common) with a named parameter and handle them correctly.

[phaedryx]

@coorasse
I think it is outside of the scope of this pull request, but as a follow-up I think, at a minimum, this method and this method should be renamed. Really, how strong parameters are handle and code like this and this should be reconsidered.

[phaedryx]

@stalniy this refactor addresses your comments

[coorasse]

this is proceeding well. it will take still some time but I have an eye on it 👍

[phaedryx]

This branch does everything I need it to do and I've fixed all of the bugs I can think of. I consider it complete.

[seanmsmith23]

Is there any reason not to use some of these features @phaedryx ? I don't think I see them documented in the wiki, but they would be useful for a project I'm working on.

[coorasse]

The feature is available and can be used. Is not well documented because we are moving the wiki at the moment. Please use it! 👍

[seanmsmith23]

Great, thank you!

[fabianprado]

Hi, i'm using this feature (so, thanks for your work 😅), and when I use it with one attribute works perfect:

can? :update, @object, :my_atribute

But when I use an array of attributes:

can? :update, @object, [:attribute_1, :attribute_2]

I get: "undefined method `to_sym' for #Array:0x000055f77c97a350."

Looking rapidly at the code, it seems like rule.matches_attributes? doesn't support an array. But looking at the comments of this PR and related issues, it should work.

It's not supported yet? Is there a workaround? Or maybe I'm doing something wrong?