Skip to content

WIP: Unify audit event details

Vladimir Shushlin requested to merge unify-audit-details into master

What does this MR do?

Currently we have 2 ways of representing audit event's details:

  1. audit events helper, which is basically concatenate keys and values like: do_something_with: "name of thing" => "Do something with: name of thing". This method is being used on project and group audit events pages.
  2. Audit::Details module which is used on /admin/audit_log and have a few special cases hardcoded(add remove failed_login custom_message), everything which is not in that list is interpreted as change.

This leads to problems:

  1. We can't use custom_message on project and group related events, since it's being shown as "Custom message: my message here"
  2. If we add new audit events to project(e.g. {add_feature_flag: "my_new_shiny_ff"}, it will be displayed in /admin/audit_log as "Change my_new_shiny_ff"
  3. Adding new event to project/group we can forget to check how it's being shown on admin/audit_log

This MR is an attempt to unify method of showing audit events without "actually fixing" details structure, which I would leave for https://gitlab.com/gitlab-org/gitlab-ee/issues/7865

I believe it's a bit better than current situation.

It also lead to some UI changes:

  1. Tense in add remove change changed Add someotheruser as developer -> User added someotheruser as Developer
  2. Bold text in add remove change changed to not bold, since on admin/audit_log it wasn't bold

What are the relevant issue numbers?

This MR was originally part of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9487 which is related to https://gitlab.com/gitlab-org/gitlab-ee/issues/9328 But I believe it should be reviewed/merged separately.

I believe we should standardise details structure as part of https://gitlab.com/gitlab-org/gitlab-ee/issues/7865

Does this MR meet the acceptance criteria?

Merge request reports