Different kinds of User.

[MrJoy]

Currently, I'm using PaperTrail, but I'm also using Avo and it looks like they're going to prefer Audited when implementing some new functionality around audit trails.

As such, I'm looking for how to handle a feature we've bolted onto PaperTrail if I migrate to Audited.

Specifically, we record different "kinds" of user -- some of which aren't things that exist in the database -- depending on the context of how a change was made.

Specifically:

If a User makes the change, we record that it was a user, along with the ID.

If a cron job makes the change (this is the overwhelming majority of actions in our system), we record a whodunnit that indicates it was a cron job, along with the name of the relevant Ruby class.

If an Administrator makes the change, via the admin UI, we record that it was an administrator performing the action, along with the ID of the administrator.

If an administrator makes the change via the Rails console, we record that it was a console user, along with the list of authorized SSH keys (typically only one) that specify who the change might've come from.

If I want to accomplish something similar with Audited, is there a relatively elegant (read: not likely to break in the future as Audited evolves) way to achieve this, or would I be in a position of having to fight the tool?

[danielmorrison]

Hm, let's think. Audited assumed one "kind" of user, not even a polymorphic join (though I'd be open to that if done cleanly).

I'd be tempted to hack the comment functionality to append what you need there.

I'm also open to a PR here. Sounds useful, but not something I'm eager to build personally.

[MrJoy]

I'll see how the Avo side of things shapes up, and look into a PR of some form depending on how that plays out.