My two cents: auditing is about (a) who did stuff, (b) what they tried to do, and (c) what happened. This quite often involves multiple models, and a good interface will hide model-level implementation details from the user. With this in mind, approaching auditing at the model level seems like a bad idea to me. I think of auditing at the controller level, where you can respond to a user action (with outcomes/status, even) as that action is attempted, even if it touches multiple models. Then you can see a 1:1 mapping between what your users do in the interface and what's recorded in the audit trail, rather than having to look at an audit trail of updates to records and work back to what they were probably trying to do in the UI.
Once you have that information, you can trawl your database or application logs for specific details, but your integration tests should ensure that when a user tries to do something in the interface, the correct sequence of actions is executed in the back-end (right?), so you shouldn't really need to go that far. If knowing what was changed is usually important for your auditing, then that sounds like a case for implementing full versioning on those models. Following this logic, though, using an off-the-shelf system makes less and less sense. Last time I had to do this, I made a generic audit message class that knew how to display itself and how to store arbitrary data, and subclassed it for each type of message I wanted to store, so that (a) only relevant stuff was written to the audit, (b) it was written in a human-readable way, and (c) I didn't need to touch the model classes to make them 'act as audited'. I also wrote a filter to ensure that auditing was called for each create/update/delete action unless I'd specifically indicated otherwise, so that I could check audit coverage throughout the app. The results were fast, smooth, and pleasing to the eye:
This is just what worked for me, and for the app I was building. YMMV. M On 15/11/2010, at 12:24 PM, Grant McLean wrote: > Hi Railers > > I would like to add an audit trail to my Rails app so that I can track > who made changes, what they changed and when they changed it - for each > record. A bit of googling led me to acts_as_audited which seems to be > loved and loathed in almost equal measures. > > Does anyone have a preferred tool for this type of thing or advice on > what did/didn't work for them? > > Another possible approach would be to do it using triggers at the DB > level rather than in Rails. > > Cheers > Grant > > -- > You received this message because you are subscribed to the Google Groups > "WellRailed" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wellrailed?hl=en. >
<<inline: audit.png>>
-- You received this message because you are subscribed to the Google Groups "WellRailed" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wellrailed?hl=en.
