Refactor AuditEvent action type
Problem to solve
The AuditEvent
model captures a variety of actions. However, the action type is not easily accessible in a record. The way it is stored is not ideal, for a few reasons:
- It is stored in a Hash-serialized
text
column calleddetails
instead of a dedicated column. - It is stored as a key in that Hash object, instead of a value. (It is assumed to be the first key, as indicated in the code.)
- It is not validated, which has resulted in unexpected values appearing in the database.
This unusual approach has created unnecessary complexity in AuditEventService
, Audit::Details
and elsewhere, and is complicating the introduction of new AuditEvent types.
List of AuditEvent action types
Audit::Details::ACTIONS
has a list of actions that is apparently incorrect. It is missing update
and with
(which appear in the database), and also has custom_message
instead of custom
. Based on some additional research it seems these are all the possible action types:
- add
- change/update
- custom
- failed_login
- remove
- with (provider login?)
- updated_ref
Proposal
The AuditEvent
data model has an action_type
attribute (with values like create/update/delete/etc) and validates attribute values are in a pre-defined set. The action_type
would be a required attribute for all new records, but we would not backfill existing records until a future issue.
Out of scope
Refactoring action values is not part of this issue. After this issue we should probably add an action
attribute (with values like protected_branch
) and validation that the attribute values are in a pre-defined set.
Availability & Testing
The audit_events
table is large (well over 85m records on gitlab.com), so any prospective changes to it need to be thoroughly tested to ensure they are performant. Specifically, deserializing the details
column for every record will require a good bit of CPU time.
Links / references
- This issue is about improving
AuditEvent
consistency, similar Implement Consistent Types fortarget_id
field