acts_as_audited Build Status Dependency Status

acts_as_audited is an ActiveRecord extension that logs all changes to your models in an audits table, with optional revision comments. acts_as_audited has been updated to work with Rails 3, to use it with older version of Rails, please see the 1.1-stable branch.

Installation

In Gemfile:

gem "acts_as_audited", "2.0.0"

In your application root, run:

$ bundle install

Generate the migration:

  • If installing without a previous version of acts_as_audited or you do not mind overwriting your audits table:

$ rails g acts_as_audited:install

  • If upgrading from a previous version of acts_as_audited you might need some alterations to the audits table:

$ rails g acts_as_audited:upgrade

  • After running one of the generators:

$ rake db:migrate

Rails deprecation warning

Currently the gem causes the following deprecation warning to be emitted:

DEPRECATION WARNING: reorder is deprecated. Please use except(:order).order(...) instead. (called from <class:Audit> at /Users/kenneth/Code/FOSS/acts_as_audited/lib/acts_as_audited/audit.rb:26)

I’m well aware of the fact, and working towards a solution. The issue has also been brought up on the Rails lighthouse as #6011. I’m keeping an eye on the issue and working towards another possible solution.

Upgrading

Upgrading to Rails 3, or even between point releases of acts_as_audited, might require alterations to the audits table. After every upgrade please run the following generator:

$ rails g acts_as_audited:upgrade

The upgrade generator will only generate migrations that are missing, or no migrations at all if you are up to date.

Usage

Declare acts_as_audited on your models:

class User < ActiveRecord::Base
  acts_as_audited :except => [:password, :mistress]
end

Within a web request, will automatically record the user that made the change if your controller has a current_user method. Comments can be added to an audit by setting model.audit_comments before create/update/destroy. If the :comment_required option is given to acts_as_audited, the save/update/destroy action will fail with add an error on model.audit_comment and triggering a transaction rollback if model.audit_comment is nil.

To record an audit for an associated model, use the :associated_with option.

class User < ActiveRecord::Base
  acts_as_audited :associated_with => :company
end

If desired, the associated model can access its audits using has_associated_audits.

class Company < ActiveRecord::Base
  has_many :users
  has_associated_audits
end

To record a user in the audits outside of a web request, you can use as_user:

Audit.as_user(user) do
  # Perform changes on audited models
end

Caveats

If your model declares attr_accessible after acts_as_audited, you need to set :protect to false. acts_as_audited uses attr_protected internally to prevent malicious users from unassociating your audits, and Rails does not allow both attr_protected and attr_accessible. It will default to false if attr_accessible is called before acts_as_audited, but needs to be explicitly set if it is called after.

class User < ActiveRecord::Base
  acts_as_audited :protect => false
  attr_accessible :name
end

Another caveat is documented in issue 26, where an audit created on the first request to the server does not have a user. Please review the Github issue for more details on how to fix this. It does not appear to affect Rails 3.

Compatability

acts_as_audited works with Rails 3.0+. For older versions of Rails, please see the 1.1-stable branch.

Getting Help

Review the documentation at http://rdoc.info/github/collectiveidea/acts_as_audited

Join the mailing list for getting help or offering suggestions.

Branches

The master branch is considered stable, and you should be able to use it at any time.

Contributing

In the spirit of free software, everyone is encouraged to help improve this project.

Here are some ways you can contribute:

  • using alpha, beta, and prerelease versions
  • reporting bugs
  • suggesting new features
  • writing or editing documentation
  • writing specifications
  • writing code (no patch is too small: fix typos, add comments, clean up inconsistent whitespace)
  • refactoring code
  • closing issues
  • reviewing patches

Submitting an Issue

We use the GitHub issue tracker to track bugs and features. Before submitting a bug report or feature request, check to make sure it hasn’t already been submitted. You can indicate support for an existing issuse by voting it up. When submitting a bug report, please include a Gist that includes a stack trace and any details that may be necessary to reproduce the bug, including your gem version, Ruby version, and operating system. Ideally, a bug report should include a pull request with failing specs.

Submitting a Pull Request

1. Fork the project. 2. Create a topic branch. 3. Implement your feature or bug fix. 4. Add specs for your feature or bug fix. 5. Run bundle exec rake. If your changes are not 100% covered and passing, go back to step 4. 6. Commit and push your changes. 7. Submit a pull request. Please do not include changes to the gemspec, version, or history file. (If you want to create your own version for some reason, please do so in a separate commit.)