• Is the user logged in? Are you using devise gem? If so (recommend), you have access to the current user using the current_user controller variable (provided by devise). Using devise with a proper authentication system is the way to go. There are alternatives to devise too.
More responses inline:
What’s the current best practice for getting the userID from the sesson,
and having it be part of every newly created/modified record?
I have an app with a Club model and a People model, and a “membership”
class Club < ActiveRecord::Base
has_many(:members, class_name: ‘People’, through: :memberships)
I want all the tables, including the membership join table, to have a
“creator” field that gets populated every time the record is created
Is created or updated? That sounds like updated_by_user_id (or last_updated_by). There are gems for that, and you should use them. I think maybe even devise may have that built-in. In which case you may not need to worry about that stuff in your controller.
I’d especially like to do stuff in my controller like the
Too much domain logic in the Controller is a common antipattern. Avoid too much domain logic in your controllers. They should be light and pass off all domain logic to context objects or model objects (or some other domain-layer).
c = Club.find(name: => ‘The Rubyists’)
c.members << People.find(name: [‘Joe’,‘Ann’])
Generally you always find things by IDs (unless you’re searching for something based on a user query). Not sure why you would want to do a find by a name.
I could see use case for this, but I’d be concerned with access control here. The cancan or cancancan gem help with access control.
and have it populate the membership table correctly.
Google has found me various articles/posts related to various versions
of rails, some of which say something like “if you’re doing this,
you’re Doing It Wrong”, and many of which suggest putting information
in a thread-local variable.
I’ve seen this pattern before (back in the Rails 1 and Rails 2 days), it is generally frowned upon at this point. Simply passing the current_user down to the model from the controller is perfectly fine in my opinion.
Consider having a class (plain-old-ruby-object) that is responsible for adding members to clubs. So in your controller, you’d write some code like this (this example is ridiculous, but is for illustrating a point)
club = Club.find(params[:id])
joe_user = User.JOE
members = [current_user, joe_user]
creator = ClubMemberCreator.new(club, members)
The ClubMemberCreator object may do a bunch of things for you (manipulate the stats about the club, spawn some worker jobs to perform operations on the memberships, send some emails to the new members welcoming them!). By putting it in its own object, you are abstracting the quickly changing logic from the slow- change logic. (see Coplien Lean Architecture), and you also moving domain logic out of the controller so it can be re-used by another controller doing the same thing. This is a good pattern and makes a lot of sense in a large app.
I worry that some of these suggestions I’ve find make assumptions about
how Rails works under the hood that may not hold true for every
That’s a good thing to worry about. Using the best tool for the job, your best judgement, and knowledge about what has worked in the past to guide you in making the least-objectionable choice.