If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.
@sgarg_gitlab I updated the issue description to ensure audit event is created for all deletion flows.
As mentioned in gitlab-com/gl-infra/production#18549 (comment 2101867159) because we link bot user to group/project via membership, creation of audit event might be challanging to implement the audit event creation in unified way, for instance if we create audit event within Users::DestroyService and bot user is being deleted via membership expiration flow, it would not be possible to get bot user project/group within the service class since we remove the membership prior to callingUsers::DestroyService.
There is existing user_destroyed | Event triggered when a user is scheduled for removal from the instance. So my suggestion to be consistent with it and create an event with name bot_user_destroyed - Event triggered when a bot user is scheduled for removal from the instance.
Also, we won't be able to create bot_user_deleted/"bot user completely destroyed" audit event and tie it to the bot user resource(group, project) because on Users::MigrateRecordsToGhostUserService stage that completely destroys the bot user its membership had been destroyed on the previous stage, we can't identify bot user resource on that stage.
By the way do we need to introduce another event type? I think we can keep using the existing user_destroyed for bot user deletion for consistency. Since bot user deletion and human or service_account user deletion are the same thing.
@bdenkovych I have introduced another event with name bot_user_scheduled_for_deletion this will provide information about bot user getting scheduled for deletion and will be available for group and project scope. We do not need another event for DestroyService Since DestroyService is the common place, I did the logging here instead of DeleteUserWorker
We do not need another event for DestroyService Since DestroyService is the common place, I did the logging here instead of DeleteUserWorker
@sgarg_gitlab Yes, Users::DestroyService is correct place to create that bot_user_scheduled_for_deletion event. My suggestion was to rename bot_user_scheduled_for_deletion to bot_user_destroyed for consistency if we can't keep using the existing user_destroyed type for bot user deletion and tie that event to its resource.
I raised the concern that if we wanted to create a new event that would indicate that user was completely removed, we would need to create this new event in Users::MigrateRecordsToGhostUserService since it is the stage where user account is completely deleted, but problem is that we won't be able to tie that event to the bot user resource because the membership is/has to be deleted on the previous deletion stage(Users::DestroyService).
By the way do we need to introduce another event type? I think we can keep using the existing user_destroyed for bot user deletion for consistency. Since bot user deletion and human or service_account user deletion are the same thing.
@adil.farrukh@sgarg_gitlab I updated the issue title and description. I still don't think that adding new event type is needed as it could increase application complexity and lead to inconsistency. I also updated the MR and requested review from groupcompliance. See !167021 (comment 2142855064) for more details.
@bdenkovych I agree we could do with one event type. But as you rightly pointed out.. I do not see any event belonging to all three scopes - User, Group and Project Since this event scope is related to project and group, I thought creating a new event type makes sense.
Thank you! @bdenkovych@sgarg_gitlab in our docs we only added the user cleanup event in !167021 (diffs). As a follow up later, would we want to document the event reasons? Or is that fairly self explanatory.