The addition of named_scope in Rails 2.1 has revealed several elegant approaches for modeling complex problem domains in ActiveRecord. One I came across recently while working on an app with a somewhat complex permissions system was a permission-based filtering mechanism. In this case I was dealing with permission for a given user to manage an “office”, while a user could be at one of three permission “levels”, one of which has specific office assignments (or it’s assumed all are manageable if user.can_manage_all_offices is true). Lot’s of necessary conditional logic there.
Now a normal approach to such a task to “show a list of offices that the user can manage” (for a drop-down for an interface perhaps) might be something like this:
# In controller:
if current_user.can_manage_company?
@offices = Office.find(:all)
elsif current_user.office_access_level? && current_user.can_manage_all_offices?
@offices.find(:all)
elsif current_user.office_access_level?
@offices.find(:all, :conditions => {:id => current_user.manageable_offices.map(&:id) })
else
@offices = []
end
But this approach starts at the user level and, using a lot of conditional logic baked right into places we don’t want, makes different calls to Office, which isn’t very DRY, and certainly not consistent with fat models skinny controllers. So I considered inverting this approach and instead starting with an office, and asking it what “is manageable by” a given user. Consider this alternative:
# In office.rb
named_scope :manageable_by, lambda {|user|
case
when user.can_manage_company? then {}
when user.office_access_level? && user.can_manage_all_offices? then {}
when user.office_access_level? then {:conditions => {:id => user.manageable_offices.map(&:id)}}
else {:conditions => "1 = 0"}
end
}
# Then in controller:
@offices = Office.manageable_by(current_user)
This seems much more elegant to me. I’m in general finding a lot of opportunities for inverting the way I designed something without named_scope to be more model-centric, so this approach helps further the design principle of “fat models, skinny controllers”. Sure you could do this before by defining your own methods and using with_scope, but named_scope just makes it all the more elegant.
Another advantage with using the named scope stuff is that you can chain scopes together. Let’s say that in another controller I want to do the same thing but instead restrict results to active offices only. I can create an “active” named scope that scopes :conditions => {:active => true}, then in the controller simply do this instead:
@offices = Office.manageable_by(current_user).active
