Simple ActiveRecord auditing.
Transcript is a simple audit library. It provides a clean interface for recording changes to a given record, including metadata about the change itself. At its core, Transcript is simply a set of concerns that expose functionality in the controller to create the log and in the model to setup relationships between the data.
Transcript differs from other auditing libraries in two ways. First, it values explicitness, exposing audit log creation near where the action takes place. Secondly, Transcript values simplicity. The core classes are only a few lines each.
Transcript is a set of Rails concerns and generators. It's intended to be used with Rails 5.0+ and Ruby 1.9.3+. It currently only works with PostgreSQL.
Add this line to your application's Gemfile:
gem 'transcript'
And then execute:
bundle
Next, run the generator to install:
rails generate transcript:install NAME
This generates a Transcript model, which can be called anything, and an initializer, specifying some configuration.
Transcript has notions of three types of models:
- the actor, which is the object taking action;
- the receiver, or the object that the actor is taking action on;
- and the Transcript model, which records these actions.
An actor can be any individual model. Because this is configured as a polymorphic association, any number of individual models can be configured as actors. To add a new actor, include the concern in the model. For example, you might have a User
model that you want to make an actor:
class User < ActiveRecord::Base
include Transcript::Actor
end
This interface sets up relationships to the log. To get a list of all the entries created by a particular actor, call the audit_entries_by
relationship:
@user.audit_entries_by # => [#<AuditEntry>, ...]
The receiver, similar to the actor, can be any individual model, and as many models as required. To add a new receiver, include the concern:
class Post < ActiveRecord::Base
include Transcript::Receiver
end
This will setup the relationships to get a list of the activities on a particular receiver:
@post.audit_entries # => [#<AuditEntry>, ...]
Sometimes you may want to have a single model that is both an actor and a receiver. For example, you may want to track changes on your user model. You can do this by including both concerns:
class User < ActiveRecord::Base
include Transcript::Actor
include Transcript::Receiver
end
@user.audit_entries_by # => [#<AuditEntry>, ...]
@user.audit_entries # => [#<AuditEntry>, ...]
The Transcript model is generated by the installer. The primary functionality is included as a concern to provide the most amount of flexibility. Since it's a module, you can override or extend the functionality in the model itself.
The generator will give you something like this:
class AuditEntry < ActiveRecord::Base
include Transcript::Model
end
The concern also includes a convenience method to get the latest audit entry:
@post.audit_entries.latest # => #<AuditEntry>
Transcript tracks some metadata about the audit entry. It logs the receiver at the top of the entry to receiver_serialized
. This is a JSONB column in PostgreSQL, which can be indexed and queried.
The controller concern provides an easy controller helper to create the Transcript record. The installation generator should inject the concern automatically:
class ApplicationController < ActionController::Base
include Transcript::Controller
end
Now, in any action, make a call to the helper. The method expects an object representing the actor and the object that is being acted upon. You can optionally pass a custom action name as a third argument as a string representing the verb (e.g. create
, delete
, or export
). If no custom action is provided Transcript will infer from the controller action it's being called in.
def create
audit_action current_user, @comment
# ...
end
def send_password_reset
audit_action current_user, @user, "password_reset"
# ...
end
Transcript includes an ActiveJob class to create audit entries in the background. However, it can also be run in synchronous mode where entries are created inline. This is handled with a configuration value, which by default is set to synchronous mode.
Transcript.configure do |config|
config.create_mode = :asynchronous # use backgrounding or :synchronous for inline
end
If you use UUIDs as the primary key, you have to manually edit the migration before running it. This is a known issue with Rails migrations using references
calls, which doesn't respect the configured primary key setting. Doing so would create something like this:
class CreateAuditEntries < ActiveRecord::Migration[5.0]
def change
create_table :audit_entries do |t|
t.string :action
t.references :actor, polymorphic: true, type: :uuid
t.references :receiver, polymorphic: true, type: :uuid
t.jsonb :receiver_serialized
t.timestamps
end
end
end
Bug reports and pull requests are welcome on GitHub. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.
Transcript is copyright © 2016 NewAperio. It is free software and may be redistributed under the terms specified in the LICENSE
file.
Transcript was developed and is maintained by NewAperio, a web and mobile engineering firm based in Baton Rouge, LA.