Rails%203%20In%20Action

170 CHAPTER 8 More authorization
The scope method provides a method you can call on your class or on an association
collection for this class that returns a subset of records. The following scope call,
for example, defines a method called admins:
scope :admins, where(:admin => true)
If you wanted to, you could call this admins method on your User model to return all
the users who are admins:
User.admins
If you didn’t have the scope method, you’d have to specify the where manually on
your queries everywhere you used them, like this:
User.where(:admin => true)
As you can see, manually specifying where isn’t nearly as pretty as simply calling
User.admins. This may seem like a contrived example, but trust us: it gets ugly when
the conditions become more complex. Scopes are yet another great example of the
DRY (Don’t Repeat Yourself) convention seen throughout Rails. Because the scope
method defines your scope’s logic in one central location, you can easily change all
uses of this scope by changing it in this one spot.
Scopes are also chainable. Imagine that you had another scope defined on your
User model, such as the following, as well as a field for storing the gender, appropriately
called gender:
scope :female, where(:gender => "Female")
You can call this scope by itself
User.female
which return all of your female users, or you can get all your female admins by doing
either this
User.admin.female
or this
User.female.admin
Rails builds up the queries by applying the scopes one at a time, and calling them in
any order will result in the same query.
Let’s define a real scope now, along with the permissions association it needs to
use. Put this scope under the validation inside the Project model, as shown in the following
lines:
validates :name, :presence => true, :uniqueness => true
B
Link to thing
has_many :permissions, :as => :thing
association
scope :readable_by, lambda { |user|
joins(:permissions).where(:permissions => { :action => "view",
:user_id => user.id })
}