is an ActiveRecord extension that logs all changes to your
models in an audits table, with optional revision comments.
has been updated to work with Rails 3, to use it with older version of Rails,
please see the 1.1-stable branch.
gem "acts_as_audited", "2.0.0"
In your application root, run:
$ bundle install
Generate the migration:
- If installing without a previous version of or you do not mind overwriting your audits table:
$ rails g acts_as_audited:install
- If upgrading from a previous version of 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 to Rails 3, or even between point releases of , 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.
Declare 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 method. Comments can be added to an audit by setting model.audit_comment
before create/update/destroy. If the :comment_required option is given to ,
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 :
Audit.as_user(user) do # Perform changes on audited models end
If your model declares after , you need to set :protect to false. acts_as_audited uses internally to prevent malicious users from unassociating your audits, and Rails does not allow both and . It will default to false if is called before , 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.
works with Rails 3.0+. For older versions of Rails, please see the 1.1-stable branch.
Review the documentation at http://rdoc.info/github/collectiveidea/acts_as_audited
Join the mailing list for getting help or offering suggestions.
The master branch is considered stable, and you should be able to use it at any time.
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.
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.)