Rails%203%20In%20Action

Restricting write access
(There’s no particular reason to put this gem underneath Devise other than that it’s
sensible to group together gems dealing with similar functions.) To install the CanCan
gem, run bundle install.
8.5.4 Adding abilities
When you run bin/rspec spec/controllers/tickets_controller_spec.rb, you get
this output:
Failure/Error: get :new, :project_id => project.id
uninitialized constant Ability
This error occurs because CanCan is now defining the cannot? method for the controller,
which uses a CanCan in-built method called current_ability:
@current_ability ||= ::Ability.new(current_user)
The ||= sets @current_ability if it isn’t already set. The :: before Ability indicates
to Ruby that you want the Ability at the root namespace. This allows you to have a
module called CanCan::Ability and a class at Ability and to differentiate between
the two. In this example, it’s trying to access just Ability, which is a class that doesn’t
yet exist.
This new Ability class will provide the link between users and their permissions.
You define it in a new file at app/models/ability.rb exactly like the following listing.
Listing 8.8 app/models/ability.rb
class Ability
include CanCan::Ability
def initialize(user)
user.permissions.each do |permission|
can permission.action.to_sym,
➥permission.thing_type.constantize do |thing|
thing.nil? ||
permission.thing_id.nil? ||
permission.thing_id == thing.id
end
end
end
end
The Ability class’s initialize method defines how can? and cannot? will act. In
this example, you iterate over all the users’ permissions and use the can? method to
say that a user can perform a specific function. Users who shouldn’t be able to perform
that function won’t have an entry in the permissions table for it. This is the
whitelist authorization described at the beginning of the chapter.
When you run bin/rspec spec/controllers/tickets_controller_spec.rb, you
get this error:
Failure/Error: get :new, :project_id => project.id
undefined method 'permissions' for #
189