#can(action = nil, subject = nil, conditions = nil, &block) ⇒ Object

Defines which abilities are allowed using two arguments. The first one is
the action you're setting the permission for, the second one is the
class of object you're setting it on.

can:update,Article

You can pass an array for either of these parameters to match any one. Here
the user has the ability to update or destroy both articles and comments.

can[:update,:destroy],[Article,Comment]

You can pass :all to match any object and :manage to match any action. Here
are some examples.

can:manage,:allcan:update,:allcan:manage,Project

You can pass a hash of conditions as the third argument. Here the user can
only see active projects which he owns.

can:read,Project,:active=>true,:user_id=>user.id

See ActiveRecordAdditions#accessible_by for how to use this in database
queries. These conditions are also used for initial attributes when
building a record in ControllerAdditions#load_resource.

If the conditions hash does not give you enough control over defining
abilities, you can use a block along with any Ruby code you want.

can:update,Projectdo|project|project.groups.include?(user.group)end

If the block returns true then the user has that :update ability for that
project, otherwise he will be denied access. The downside to using a block
is that it cannot be used to generate conditions for database queries.

You can pass custom objects into this “can” method, this is usually done
with a symbol and is useful if a class isn't available to define
permissions on.

can:read,:statscan?:read,:stats# => true

IMPORTANT: Neither a hash of conditions nor a block will be used when
checking permission on a class.

can:update,Project,:priority=>3can?:update,Project# => true

If you pass no arguments to can, the action, class, and object
will be passed to the block and the block will always be executed. This
allows you to override the full behavior if the permissions are defined in
an external source such as the database.

cando|action,object_class,object|# check the database and return true/false
end

#can?(action, subject, *extra_args) ⇒ Boolean

Check if the user has permission to perform a given action on an object.

can?:destroy,@project

You can also pass the class instead of an instance (if you don't have
one handy).

can?:create,Project

Nested resources can be passed through a hash, this way conditions which
are dependent upon the association will work when using a class.

can?:create,@category=>Project

You can also pass multiple objects to check. You only need to pass a hash
following the pattern { :any => [many subjects] }. The behaviour is
check if there is a permission on any of the given objects.