|TODO: this content has not yet been reviewed/updated for v2.0|
The Auditer module provides an implementation of the EntityPropertyChangeSubscriber, as well as a number of related domain services,
It creates an audit record for each changed property (ie every time that
AuditerService#audit(…) is called.
The module also provides:
AuditingServiceMenuservice which provides actions to search for
AuditEntrys, underneath an 'Activity' menu on the secondary menu bar.
AuditingServiceRepositoryservice to to search for persisted
AuditEntry``s. None of its actions are visible in the user interface (they are all `@Programmatic).
AuditingServiceContributionswhich contributes collections to the HasInteractionId interface. This will therefore display all audit entries that occurred in a given request/transaction, in other words whenever a command, a published event or another audit entry is displayed.
These services can be activated by updating the
pom.xml and updating the
If menu items or contributions are not required in the UI, these can be suppressed either using security or by implementing a vetoing subscriber.
The typical way to indicate that an object should be audited is to annotate it with the @DomainObject#auditing() annotation.
The auditing service works very well with implementations of ExecutionSubscriber that persist the
Execution objects obtained from the InteractionContext service.
The interaction execution captures the cause of an interaction (an action was invoked, a property was edited), while the
EntityPropertyChangeSubscriber audit entries capture the effect of that interaction in terms of changed state.
The CommandSubscriber SPI can also be combined with the audit-trail service, where the
Command capturesthe intent of an action, not the actual action invocation itself.