Support audit logging of non-entity based events

Problem/Motivation

In many industries that are under strict regulatory oversight (such as financial or healthcare), it is required to provide a detailed audit trail of all changes made to an application. In some cases, it may also be desirable to store the actual serialized before and after object data in the audit log.

As such, this module should either provide natively or offer a means for other modules to provide audit tracking on at least the following items:

• Module enable/disable.
• Site configuration changes.
• System Configuration form submissions.
• Pageviews by authenticated users (in some cases, HIPAA requires that you be able to tell an auditor which content has been viewed by which users within a certain time frame)
• Changes to Media or other types of non-node entities.

Site administrators should be able to control which items to audit track based on the needs of their site.

Proposed resolution

There are several ways to approach this problem depending on whether we want these features to be included within the module itself or if we want to allow other modules to extend the audit_log module. Though there is a lot of overlap between both paths.

Allow other modules to extend audit_log

• Make API and Schema changes listed below.
• External modules would call \Drupal::service('audit_log.logger')->log() directly to report an auditable event. (alternatively, we could change the audit_log module so that we define an Event and EventSubscriber architecture where the external modules would raise an audit_log event (https://api.drupal.org/api/drupal/core!core.api.php/group/events/8.2.x)
• When building the administrative UI, provide hooks, events, or a plugin architecture for external modules to include their own configuration and display formatters.

Including this functionality within audit_log

• Make API and Schema changes listed below.
• Directly implement handlers for each of the above types of logging.
• Build administrative UI that allows selecting which actions and objects are logged.

User interface changes

TBD.

API changes

Modify the log() method of the service 'audit_log.logger' to take an AuditLogEventIterface object rather than an EntityInterface object as a parameter.

Modify the hook_entity_action() methods in audit_log.module to build an AuditLogEvent object and pass that to the audit_log.logger service rather than passing the raw entity. I would suggest modifying the AuditLogEvent object definition so that the class constructor takes a passed entity and action string rather than setting individual properties on the class.

Data model changes

We will need to make the names on some of the Event object properties more generic. For example:

• EntityID => ObjectID
• EntityType => SourceType
• Add properties for before/after data snapshots.