Let's start our journey into the abilities definition by explaining the CanCanCan Hash of conditions mechanism.
In the chapter Define and Check Abilities we defined
can :update, @article, user: user
to say that an Article can be updated only by it's author. But how does it work?
The third argument of the can
method ({ user: user }
) is the hash of conditions for this rule.
A hash of conditions can be passed to further restrict which records this permission applies to.
In the example below the user will only have permission to read active projects which they own.
can :read, Project, active: true, user_id: user.id
When defining a condition, the key should always be either a database column of the model, or the association name. In the example above, if the Project has defined
belongs_to :owner, class_name: 'User', foreign_key: :user_id
the rule can also be written as:
can :read, Project, active: true, owner: user
so by using the association owner
instead of the database column user_id
.
You can nest conditions associations. Here the project can only be read if the category it belongs to is visible.
can :read, Project, category: { visible: true }
An array or range can be passed to match multiple values. Here the user can only read projects of priority 1 through 3.
can :read, Project, priority: 1..3
If you want to a negative match, you can pass in nil
.
# Can read projects that don't have any members.
can :read, Project, members: { id: nil }
Almost anything that you can pass to a hash of conditions in ActiveRecord will work here as well.
All associations can be traversed when defining a rule.
class User
belongs_to :account
end
class Account
has_one :user
has_many :services
end
class Service
belongs_to :account
has_many :parts
end
class Part
belongs_to :service
end
# Ability
can :manage, Part, service: { account: { user: user } }
Let's now quickly see how to Combine Abilities