I'm not sure I understand the question. Here's what gets typed:

  ssh foo.example.com #uses private/public key per conf file
  *enter password*
  cd app
  ruby script/console
  irb > u = User.find_by_email "customer@example.net"
  irb > u.authorize_ghosting! "Reason for log goes here."
  * you'll want to incognito mode the URL returned here*
  irb > exit
  exit

With all due love and respect:

This is something I would wrap a simple CLI around, and then kick myself in the tukhus for having ever used the language's interactive client to make raw database queries and edits on the production server.

'find_by_email' is what counts as a raw database query these days? I feel so old.

At my company, using an interactive shell on prod to invoke DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden. It's untested code coming straight from your fallible fingers and manipulating the prod database. I don't see why this should be treated as any different than a raw db query. You can do some pretty powerfully destructive stuff with an ORM.

If there's anything destructive about that interactive session, it's likely to be the 'authorize_ghosting!' call. Somehow, I find it hard to believe sticking it in a one line script would make it less destructive, but let's see.

    User.find_by_email(ARGV[0]).authorize_ghosting!(ARGV[1])

Oh, yes, so much better. patio11 should totally switch to using this. And then pay me my $1000 consulting fee.

I'm going to go out on a limb and suggest that it shouldn't just be turned into a one-liner that shoves ARGV elements directly at the database, but should actually do some validation of input. Even your one-liner is safer than raw irb since you can't make a typo and call the wrong method, but if you add validation, then yes, I think it's much, much less destructive.

What sort of validation? Either you provide a valid email address that exists and it works, or not.

I suppose when the args are both allowed to be arbitrary strings, the validation is already done, and the escaping is done by AR, so you can safely pass them unmolested. It just triggers my safety reflex to send ARGV elements on to the next layer without doing something to them.

My previous company had "read-only" credentials to production.

...however, this is obviously not an operation you could do with readonly access.

I was responding to this:

> DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden

You can run raw DB queries against read-only credentials.

Ah, yes, that obviously should have been qualified as DB writes.