Moderators audit logs

[benhalpern]

Moderators and admins take certain actions on the platform. Those actions can be discovered with certain breadcrumbs in our deeper app logs, the various things being created and destroyed, but we don't currently have a useful record of all actions taken.

I think it would be worth creating a table called mod_actions or something like that. It would be a table that we append to any time a mod or admin does anything. For better overall auditing of what happened and when. It would be visible to other mods within a tag and for all admins to pay attention to.

I think others might have better insights on how to think about it, but I feel like these would be my high level feature thoughts:

• Who took the action (a user ID)
• What category (tag moderation, general community moderation, admin action, etc.)
• Info about that user's mod/admin roles at the time (which could change over time but this keeps it as a moment in time
• markdown to capture all info about the action, generated contextually to include relevant links etc.
• a dedicated name/slug for the type of action it was, e.g. tag removal, downvote, vomit vote, and all the other types of actions we might take. We could keep adding to this list as we go.

It should define an API to let us drop log lines in where relevant. They should execute with the lowest footprint possible, so they should execute asynchronously.

This would be a very helpful feature! I feel like it doesn't need a ton of existing knowledge of our codebase to implement in and of itself.

[brarnaudovski]

Hi @benhalpern . I want to start with this feature. My plan is to use custom events using Rails active support instrumentation

I am just wondering how to make the custom payload for categories, markdown info, action/slug and so on.
This should be different for different model/controller action, right?

[benhalpern]

Hey @brarnaudovski this sounds great!

I've never used ActiveSupport::Notifications but it definitely seems like the right tool for the job and I'll be interested to follow along.

I don't think you'd need a custom payload if I understand this correctly, as the general schema of the data being passed would be consistent.

@lightalloy can you help guide this?

[lightalloy]

Hey @benhalpern, @brarnaudovski.
As I understood, the structure can be pretty consistent:

• user_id
• role_id (or name, but roles seem to be consistent)
• action (name/slug)
• data (info about the action)
  It's not clear to me why we should use markdown for this kind of information. I would use a jsonb field for it. @ben, could you explain the choice of the markdown format?
  If we need a custom payload for different actions, it can be stored in the data field.

I have read about the ActiveSupport::Notifications but haven't used them yet. I agree that they seem like the right tool for this task.

[lightalloy]

Besides the actual logging (implemented in #3449), I suppose the interface for admins would be useful. For now, that could be a simple paginated list in /internal. The only problem with /internal is that new items don't fit in the navbar (check out this comment for the context #3997 (review) )