Objective: The purpose of audit logging within OpenLMIS is to create a complete picture of all relative state changes as they occur within the system in order to encourage confidence on behalf of the user community.
A record of all state changes for all objects within the system. For all records within OpenLMIS, one should be able to trace backwards from a records present state, all the way back to its initialized state. Records of state changes should be immutable.
For example, if a facility has the following attributes when instantiated:
Facility
| FacilityName | FacilityId | Type | LatCoord | LonCoord |
|---|---|---|---|---|
| Steinbach Hospital | F123 | Hospital | 30.113 | 19.210 |
and it is updated to be:
Facility
| FacilityName | FacilityId | Type | latCoord | lonCoord |
|---|---|---|---|---|
| Steinbach Hospital | F123 | Clinic | 30.111 | 19.210 |
There should be a record of the change, when the change occured, and who made the change. That is, our original table should be extended to show the following state data:
Facility
| FacilityName | FacilityId | Type | LatCoord | LonCoord | CreatedBy | CreatedDate | LastModBy | LastModDate |
|---|---|---|---|---|---|---|---|---|
| Steinbach Hospital | F123 | Hospital | 30.113 | 19.210 | KevinCussen | 2016-01-01 01:01:01 | null | null |
When the change is made, this table row should be updated to reflect the new data. For example, if John Smith has made the changes to Steinbach Hospital record on January 20th, the updated record would show the following:
Facility
| FacilityName | FacilityId | Type | LatCoord | LonCoord | CreatedBy | CreatedDate | LastModBy | LastModDate |
|---|---|---|---|---|---|---|---|---|
| Steinbach Hospital | F123 | Clinic | 30.111 | 19.210 | KevinCussen | 2016-01-01 | JohnSmith | 2016-01-20 12:34:56 |
Additionally, the previous state of the record should be recorded as a historical entity. Any time an update is made to a record, a log of the previous state should be persisted. One approach is as follows (though no approach is proscribed):
Facility_StateChangeRecord
| FacilityName | FacilityName_ChangedTo | FacilityId | FacilityId_ChangedTo | Type | Type_ChangedTo | LatCoord | LatCoord_ChangedTo | LonCoord | LonCoord_ChangedTo | CreatedBy | CreatedBy_ChangedTo | CreatedDate | CreatedDate_ChangedTo | UpdatedBy | UpdatedBy_ChangedTo | LastModDate | LastModDate_ChangedTo |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Steinbach Hospital | null | F123 | null | Hospital | Clinic | 30.113 | 30.111 | 19.210 | null | KevinCussen | null | 2016-01-01 | null | null | JohnSmith | null | 2016-01-20 12:34:56 |
Pengfei - Are you familiar with Envers? If this is a feasible solution, Mary Jo Kochendorfer and I will work through our ERD model and define which classes and class variables should be audited. Please schedule some time to discuss with me.
As an administrator, I want an audit log/trail on any object or process in the system. For example, I want to know who changed values on a Facility record, changes to a Requisition template, a log of the approvals on a Requisition, log of all requisition status changes.
These examples were deliberately chosen to show logging on 1) individual record/entity 2) to a composed entity (a Req template is likely a composition of many sub-objects), or a process. This may call for different types of logging. We may also wish to configure which entities are logged, e.g. do we really need to log changes on everything?
Levels
Individual record/entity logging
Composed entity (requisition template, order file template)
Process
Application usage
This might be its own epic.
Acceptance:
- The system logs changes for entities, including the old value, new value, the user who made the change, and the change date.
- The audit trail for a given object may be easily retrieved (via API) and displayed in the UI
- Audit log feature may be easily leveraged by any OpenLMIS independent Service