Refactoring Student Team Controller

Hey Andrew. Please take a look at our recent changes to the Student Team Controller.

We've allready renamed it "StudentTeamsController" but we were also concerned that there is no such thing as a "StudentTeam", there is really only an "AssignmentTeam", so the controller should probably be "AssignmentTeamsController". That being said, the worker itself uses the current login more as the primary target. confusion here seems to be from the model structure used.

In addition, many of the more complicated management in the controller is record keeping-which we think would be better taken care of through relationships. Some of these relationships are allready in place in some way or another,  but some (like the `has_many :users, :through => :teams_user` in Team) are done in a non-standard way. Without extensive testing on both the controller and the models, we are a little nervose to make such sweeping changes. We also readily admit that none of us are testing experts or experts on the Expertiza system, so the "white box" testing we'll be doing will be pretty high risk. Do you have any advice?
yes and no. We'll have to reimplement a "filter" type in action_allowed, which will look something like this:

  def action_allowed?
    if current_role_name.eql? ("Student")
      return !current_user_id?(@student.user_id) if [:view, :create, :edit, :leave].include? action_name
      return true
    else
      return false
    end
  end

or 

return current_role_name.eql? ("Student") && (
    ![:view, :create, :edit, :leave].include? action_name || !current_user_id?(@student.user_id)
    )

Both of which are pretty ugly. I'll go ahead an implemenet it this way as it'll handle the errors more correctly, but we may want to update action_allowed? as its own callback type (executed after any other before_filters) which would allow use of the same style filters as the inline filters.

Something to thing about (feel free to ignore this):

I find it a little funny that the permissions are defined in the controller itself, it seems like mixing roles.

In addition http://apidock.com/rails/v2.3.8/ActionController/Resources/Resource/action_allowed%3F shows that action_allowed? was a builtin in 2.38, http://api.rubyonrails.org/ doesn't contain any documentation for action_allowed?, so it looks like AccessHelper is reviving something that the rails community decided to put to rest, which makes me nervose in general.

In a different project, I had a similar approach to this, but permissions were stored as a 3 level model, which would allot them to be configured via the web interface (similar to how Redmine does it). For a target and action, the action would have 3 possible levels of permissions: "all" "none" and "owned".  Permission had a class method that way `may?(user,action,model)`. Users could call this indirection, with a `may?(action model)` or a method-missing parse may_{action}_{model}?

The "action_allowed?" in the controller was added as a concern so it was only done on relevant controllers. It was done two steps: first they checked for `all` or `none`, which would prevent an uneeded database lookup of the target.  Then, after the member variables were set, the target was asked if the current user could do an action polymorphically (Does X own you in this capacity).

This was much more flexible than the action_allowed? system, but it also more people to check permissions, which allowed things like conditionally showing links in the views:

<%=link_to: edit_student_teams_path id: @team.id if current_user.may_edit_student_team(@team)%>

What I didn't like about this method was that the target models were aware of the "actions"...I'd love a design where all permissions were handled in a "Permission Controller".