Auditer

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:

  • AuditingServiceMenu service which provides actions to search for AuditEntrys, underneath an 'Activity' menu on the secondary menu bar.

  • AuditingServiceRepository service to to search for persisted AuditEntry``s. None of its actions are visible in the user interface (they are all `@Programmatic).

  • AuditingServiceContributions which 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 AppManifest#getModules() method.

If menu items or contributions are not required in the UI, these can be suppressed either using security or by implementing a vetoing subscriber.

Usage

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.