Record and track changes to any dataobjects. View chages/diffs in model admin.
- SilverStripe 3
Record and track changes and deletes of any dataobjects. View changes/diffs in model admin.
Additionally, track add/remove of items in many_many relationships
Install via composer, run dev/build
composer require silverstripe-australia/datachange-tracker
Add the ChangeRecordable extension to the dataobjects you wish to track
MyDataObject: extensions: - ChangeRecordable
If you are applying the extension to the SiteTree, use the SiteTreeChangeRecordable extension to record publish/unpublish actions
To track changes to many_many relationships, you must use a custom ManyManyRelationship class, as well as indicate which relationships need tracking. This can be directly configured via the Injector
Injector: ManyManyList: class: TrackedManyManyList properties: trackedRelationships: - Page_Regions
will track the "Regions" relationship defined on the Page class;
private static $many_many = array( 'Regions' => 'SomeObject', );
save_request_vars option to 1, and GET and POST vars will be recorded too.
DataChangeRecord: save_request_vars: 1
In some cases it may not be desirable to track changes to all fields of an object. You can define ignored fields in your yml config like so:
ChangeRecordable: ignored_fields: NameOfObjectClass: - NameOfField
Or, for the same field name across all objects
DataChangeRecord: field_blacklist: - Password - Email
Also, you may wish to blacklist some request variables from being stored
DataChangeRecord: request_vars_blacklist: - url - SecurityID
Sometimes reporting changes to certain fields to CMS users is desirable (e.g seeing the last time a field was updated).
This is handled by
SignificantChangeRecordable, which looks for a list of
TeamMember: significant_fields: - 'Name' - 'Address' - 'OfficeNumber' - 'Position' - 'Mobile' extensions: - 'ChangeRecordable' - 'SignificantChangeRecordable'
Over time, the data recorded will become overwhelming in size. May not be a problem for you, but if it is
you can regularly prune it to retain just (N) months of data at a time. Simply create the
from the QueuedJob admin section of the CMS, using a constructor param of something like "-6 months".
The job will restart itself to run each night, to consistently remove the past 6 months of data.
- Added pruning of data via queuedjobs
- Removed static DataChangeRecord::track() method