User auditing with acts_as_audited

acts_as_audited | plugin | rails November 19 2006

Thanks to Chaz for pointing out the section in the Rails Recipes book about using Rails’ cache_sweeper to implement auditing. I’ve updated acts_as_audited so that it can quickly and easily audit modifications to your models along with the user that made the change. Check out the original post for more information and examples of how to use it.

posted by brandon
comments feed

4 comments

  1. Dear Brandon:

    Thanks for the nice plugin. I just played with it a bit.

    Here is a suggestion for your consideration. For destroy operation, the plugin doesn’t store anything on the changes column. However for new operation it does store the entire new record. Wouldn’t it be a good idea to keep the destroy and create at the same level so that when I know something got deleted, I know the contents of the deleted record also?

    Thanks, Venkat.

    Venkat Venkat
    December 24, 2006 at 10:35 AM

  2. Venkat – you may consider using act_as_audited in combination with acts_as_paranoid (which marks but doesn’t actually delete records).

    Jodi

    Jodi Jodi
    January 28, 2007 at 01:26 PM

  3. Have you tried acts_as_audited with single table inheritance?

    I have an AbstractMembership class, which extends ActiveRecord, is instructed to use the memberships table and is marked abstract. The table has a type column to support STI.

    Then I have Membership, NewMembershipRequest, ChangeMembershipRequest and RemoveMembershipRequest, each of which extends AbstractMembership. Only Membership acts_as_audited, but the plugin records audits for the other subclasses of AbstractMembership as well.

    Which is weird, I think. Worse, when it creates these audits, the auditable_type is always Membership.

    It’s almost like acts_as_audited is digging its claws in too high up the class hierarchy. Any advice?

    Sheldon Hearn Sheldon Hearn
    May 01, 2007 at 04:11 PM

  4. Ah, yes. The class variable vs. class instance variable problem.

    I have tried it with STI, but I wanted all the instances to be audited, so it worked fine for me.

    I’ll look into this tonight. Most likely what is happening is that acts_as_audited is using class variables, which are shared throughout the inheritance hierarchy, instead of class instance variables (I wrote the plugin before I had any idea that there was a difference).

    Worse, when it creates these audits, the auditable_type is always Membership.

    This is actually intended behavior. I’ll need to verify this, but I believe polymorphic associations use the name of the base AR class in STI.

    Brandon Brandon
    May 01, 2007 at 04:28 PM

Speak your mind:

(Required)

(Required)


(You may use textile in your comments.)

About

I'm Brandon Keepers, a web application developer that likes beautiful code, valid markup and adherence to standards. As a part of Collective Idea in Holland, Michigan, I practice Agile software development primarily using Ruby on Rails.

-86.103171 42.785037

Contact:

more ยป

Links

Syndicate