WIP: Unify audit event details
What does this MR do?
Currently we have 2 ways of representing audit event's details:
- 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. - 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 aschange
.
This leads to problems:
- We can't use
custom_message
on project and group related events, since it's being shown as "Custom message: my message here" - 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" - 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:
- Tense in
add remove change
changedAdd someotheruser as developer -> User added someotheruser as Developer
- Bold text in
add remove change
changed to not bold, since onadmin/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?
-
Changelog entry added, if necessary -
Documentation created/updated via this MR -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Tested in all supported browsers -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
Conforms to the database guides -
Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process. -
EE specific content should be in the top level /ee
folder -
For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan? -
Security reports checked/validated by reviewer