Deprecate Ghost User

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

• Close this issue

Problem to solve

Currently it is possible for admins to permanently delete users without deleting their associated records (issues, MRs, comments, etc). This is accomplished by irreversibly moving their associated records to the ownership of a shared "Ghost User". This "ghostification" creates some problems:

1. Compliance. The process of ghostification effectively deletes the record of who did what. It is still clear what happened, but not who did it. This is a major problem for compliance programs like SOX.
2. Complexity. The process of ghostification is complex. Moving all of one user's associated records to another user is like picking up a house and moving it to a new foundation. Yes, it can be done. But it is requires lots of time, effort, and special equipment, and even with your best efforts the house might have problems afterward. The complexity of ghostification has prompted lots of bugfixes and feature requests that would not be necessary with a simpler solution (see the list below). In particular, there is currently a proposal to create a unique Ghost User for every deleted user, which would partially improve the compliance problem, but at the cost of worsening complexity.

Proposal

It should not be possible to delete a user without deleting the user's associated records. We should deprecate Ghost User, although it must continue existing where it is already in use, because we have no way to roll back.

To be more specific, a user should continue to be deletable by an administrator, however:

• Users should NEVER be deleted without deleting all associated records. (This means we should stop using the Ghost User, although we should allow it to continue existing where it is already in use, because we have no way to unwind it.)
• Users should NOT be able to delete themselves if they have group/project contributions, because those contributions have become "community property". (Question: How can we allow for conscientious deletions?)
• Administrators SHOULD be able to delete users (including all associated records) if they have group/project contributions. (This is already possible with the hard_delete argument.) This is for handling bad actors like spammers. Administrators should be strongly warned: "This will DELETE absolutely everything the user has ever done, including comments, commit pushes, etc."

Related links

• Documentation about two options for deleting users
• The "ghost user" concept was first introduced in gitlab-foss!7393 (merged), under gitlab-foss#12726 (closed). That issue had a follow-up: gitlab-foss#28695 (closed)
• The original discussion about how to solve this problem appears to have been lost. Apparently "there [was] no clear consensus" there. It doesn't seem like there was clear consensus in the successor issue either. In other words, it seems like "ghost user" was a best-guess experiment.
• This proposal would extend to pending operations, like delayed deletion of projects and groups. If a user requests delayed deletion, then is fully deleted before their deletion request is executed, then that deletion request should also be deleted.

Some of the bugs related to "ghost user"

(One small example is hard delete of user results in nil author,

• Audit Events page shows ghost-user-1 instead of the user name (2021; open)
• Scheduled project and group deletion jobs fail every day, forever, if the deleting user is itself deleted before the deletion job is performed (2020; open).
• Exported ghost user is mapped to the user that triggers the import (2019; open)
• Hard delete of user results in nil author (2019; open) - this is ironic because it was said in 2016 that we "would expect note.author or issue.author never be nil in the code" as a result of the ghost user.
• Sign up page is not redirected correctly if ghost user is added after upgrading and migrating databases. (2018; open)
• Undefined behavior in User#abuse_report (2017; closed)
• Deleting a user blocks a user due to a deadlock condition with ghost user (2017; closed)

Impact on importers

If this is implemented, it should be communicated to Import group, as importers are mapping ghost users contributions from source to ghost users on destination instance. See Direct Transfer - Contributions of ghost user s... (#514014 - closed).