Docs: Organize the feature list

It's still too long for my taste, but this way people can just
scan the top-level bullet points.

[ci skip]
This commit is contained in:
Jared Beck 2015-08-06 11:33:32 -04:00
parent b6070c4548
commit d8651f22a3
1 changed files with 22 additions and 21 deletions

View File

@ -31,27 +31,28 @@ revert it to any version, and even undelete it after it's been destroyed.
## Features ## Features
* Stores every create, update and destroy (or only the lifecycle events you specify). * Stores create, update and destroy events
* Does not store updates which don't change anything. * Does not store updates which don't change anything
* Allows you to specify attributes (by inclusion or exclusion) which must change for a Version to be stored. * Support for versioning associated records
* Allows you to get at every version, including the original, even once destroyed. * Can store metadata with each version record
* Allows you to get at every version even if the schema has since changed. * Who was responsible for a change
* Allows you to get at the version as of a particular time. * Arbitrary model-level metadata (useful for filtering versions)
* Option to automatically restore `has_one`, `has_many` and `has_many :through` associations as they were at the time. * Arbitrary controller-level information e.g. remote IP
* Automatically records who was responsible via your controller. PaperTrail calls `current_user` by default, if it exists, but you can have it call any method you like. * Configurable
* Allows you to set who is responsible at model-level (useful for migrations). * No configuration necessary, but if you want to ..
* Allows you to store arbitrary model-level metadata with each version (useful for filtering versions). * Configure which events (create, update and destroy) are versioned
* Allows you to store arbitrary controller-level information with each version, e.g. remote IP. * Configure which attributes must change for an update to be versioned
* Can be turned off/on per class (useful for migrations). * Turn off/on by model, request, or globally
* Can be turned off/on per request (useful for testing with an external service). * Use separate tables for separate models
* Can be turned off/on globally (useful for testing). * Extensible
* No configuration necessary. * Write a custom version class for complete control
* Stores everything in a single database table by default (generates migration for you), or can use separate tables for separate models. * Write custom version classes for each of your models
* Supports custom version classes so different models' versions can have different behaviour. * Work with versions
* Supports custom name for versions association. * Restore any version, including the original, even once destroyed
* Thoroughly tested. * Restore any version even if the schema has since changed
* Threadsafe. * Restore the version as of a particular time
* Thoroughly tested
* Threadsafe
## Compatibility ## Compatibility