Audit Events - Log initial trigger of project and group deletions, and/or make it clear why deletions are taking place

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

Audit events currently log removal actions such as group and project removals as they're taking place, however the logged events do not clearly tie these deletions to the original action(s) that triggered the deletions.

In certain cases such as if a sole owner of a group has their user account deleted, we see the resulting removal of projects and subgroups in the audit logs, however there is neither any preceding logged action, or log details on the removal actions themselves to clearly indicate why the deletions are occurring.

This resulted in an emergency situation with a Large Ultimate customer wherein large amounts of groups and projects were being removed as part of a user account removal action, however the audit events did not indicate anything useful as to why this was happening as it was occurring. Such details should be clearly available in the audit logs both for retrospective auditing purposes, and also to potentially identify the cause of unintended ongoing deletions, which may speed up the time to identify the cause and halt further deletions from taking place.

• Zendesk ticket (internal use only)

Steps to reproduce

For example, we can try removing a sole remaining owner of a group, where the group may have many underlying subgroups and projects.

1. Delete a user whom is a sole remaining owner of a group, along with their contributions.
2. Check the instance audit events after performing the deletion

What is the current behavior?

The sequence of audit events will appear as follows after triggering a deletion of a sole remaining group owner user:

1. Removed project actions are logged:

   • 

2. Removed group actions are logged:

   • 

3. The user removal is logged after all of these deletions:

   • 

What is the preferred behavior?

• There should be an audit event log entry showing that a user deletion action has taken place, which also specifies the user that triggered the action. This needs to logged before the subsequent contribution deletion logs. In cases where a user deletion has queued up large amounts of contribution deletions, it's ideal to see this logged clearly at the start of the event sequence so that we can look at the audit events and see exactly why deletions are occurring, rather than the current situation where we only get an idea of what has happened after all of the contribution deletions have been logged, and we see the log of the actual user's account deletion occurring.

• If possible, have a way for each individual deletion action to be clearly tied back to the initial action that triggered it.