Audit events in admin interface of user edits

Zendesk: https://gitlab.zendesk.com/agent/tickets/15224

description

Show audit events in the admin screen for the following actions:

• a user is created
• a user is blocked
• a user is deleted

original issue

I recently worked with a customer that had some strange things happen with a user being added, granting some permission and then the user was deleted. We can look up what happened in the application.log but it seems it would be nice to have audit events about global changes in the admin area. Events may include users created/blocked/deleted from the system as well as other global tasks are they are deemed useful.

This doesn't seem like a ton of work. We can just hook in any place that is currently writing to application.log. We can basically re-use the views from group/project events. It's not urgent, but a nice to have.

cc/ @JobV @dzaporozhets What do you think?

Here's a customer that requests we add configuration change events to audit events. https://gitlab.zendesk.com/agent/tickets/15224

@dblessing make a list of possible events? Then we can schedule it.

@JobV To begin with let's just do user create, block, delete. We can expand later.

Title changed from Add audit events to admin area to Audit events in admin interface of user edits

Milestone changed to 8.9

Added ~113221 label

Added promised label

OK

mentioned in commit d2721c23

Added audit events label

Removed audit events label

Added audit events label

Removed audit events ~113221 feature proposal promised labels

Milestone changed to %8.10

Added audit events ~113221 feature proposal promised labels

Reassigned to @vsizov

By the way we already have application.log in admin area. UPDATE: But it shows when user is created and that's it

Assignee removed

@JobV Maybe we should just extend the application logging? I mean logging of all mentioned events to the application.log as well.

@vsizov that's a good start.

Milestone changed to %8.11

Added ~481018 label

Reassigned to @vsizov

Because we don't have an admin audit log now, we decided to just log the user blocked events to application.log in GitLab CE. In the future we can consider creating a separate Admin audit log.

After further consideration I think extending application.log is a bad idea. The logic that logs all data is placed in model callbacks. The user has requested ability to see who and what has been done. In model callbacks we don't have information about who has triggered that event. So if we extend the logs it will be useless anyway. So it looks like we need to implement separate audit log in admin interface and place all the logic into services.

Milestone changed to %8.12

FYI. Browsing through EE issues, I've found these other audit issues that might be relevant to choose how we deal with these logs from that point onward:

• Add visibility changes of project to the audit logs https://gitlab.com/gitlab-org/gitlab-ee/issues/199
• Add audit event entry when a group share is added/removed https://gitlab.com/gitlab-org/gitlab-ee/issues/205
• Audit logs for API access https://gitlab.com/gitlab-org/gitlab-ee/issues/68

mentioned in issue #579

Milestone changed to %8.13

Milestone changed to %8.14

Assignee removed

Mentioned in commit d2721c23

Milestone changed to %Backlog