Question

My model holds expenses, including user and project references..

class Expense < ActiveRecord::Base
     attr_accessible :amount, :expense_date, :description, :project_id, :user_id

      belongs_to :project
      belongs_to :user
end

The ExpensesController handles basic CRUD operations for the expenses.

I now am needing to build an administrators version of this same page, a new view preferably, which can include the different views of the data, by user, by project, etc, and can also edit data that the user cannot.

My question is: Do a build a second controller to handle the administrative perspective of the data, — or do I setup conditions inside of every method, to detect the originating view and form, and then conditions to redirect them back to where they belong?

If I do build a second controller, how do I properly setup the form_for so that it knows what controller to go to?

Thanks!

PS – If anyone has any books about how to properly put together a rails app, I feel like I know the pieces ant parts, but I’m getting stuck on the big picture implementation. I learned rails with Michael Hartl’s guide, prior to that I was a PHP developer.

Answer 1

IMHO, if security is a big concern for your app then using an admin namespace and separate controllers is the best way to make sure you don’t leave any gaps. It’s also just simpler and lower stress.

I would have a directory structure like so:

/app/controllers/application_controller.rb
/app/controllers/admin_controller.rb - inherits from application_controller
/app/controllers/expenses_controller.rb - non-admin, inherits from application_controller
/app/controllers/admin/expenses_controller.rb - inherits from admin_controller

Your views would be similarly separated/duplicated:

/app/views/expenses/* - non-admin expenses views
/app/views/admin/expenses/* - admin expenses views

In application_controller you’d put the Devise methods to authenticate_user and CanCan method to check_authorization (which throws an exception if authorization is not checked at some point in the controller action). In admin_controller you have more strict filters to make sure the user is an admin. Then you can get even more fine-grained in the specific controllers and their actions.

Of course each controller only has to define the actions it really needs and you don’t have to duplicate views. Maybe the non-admin expenses_controller has index, show, new, create, while the admin one has only edit, update, and destroy. Then in the ‘show’ view you’d still have code that add links to the ‘edit’ action if the user is an admin.

Edit – Routes

With the above example, your routes.rb would look something like:

resources :expenses, :only => [:index, :show, :new, :create]

namespace :admin do
  resources :expenses, :only => [:edit, :update, :destroy]
end

So you still use expenses_path() for the index and expense_path(foo) for show. A form on the admin page, however, would post to admin_expense_path(@expense).