When an account is deleted, the username in the user's posts and comments is changed to a generic user<userID>. But the username stays the same on close and delete notifications on posts the user had voted to close / delete1. I think it shouldn't, especially for users who used their real name as their username, if they chose to distance themselves from the site and remove their accounts, it makes sense that they wouldn't really want their name plastered on close and delete notifications.

A perhaps easy way to avoid the actual username remaining visible would be to change it to the generic user<userID> (or anything generic enough, like "anonymous") prior to deletion, and wait a bit for the generic username to propagate all over the site. If I'm not horribly misreading this answer, this was part of the process in the old days.

This could be automated or added as a suggestion to the account deletion help page.

Glaring example can be seen here, where the deleted user also posted a comment where their name is properly anonymized:

enter image description here

1 I've seen it on close notifications and self deleted answers. I'm not sure it happens on deleted questions, or deleted answers that aren't self deletions, and I don't have a way to verify it - other than stumbling on them accidentally

  • 3
    It happens in deleted questions as well. I see no reason why it would be different in deleted answers. Nov 16, 2012 at 16:36
  • @NullUserExceptionอ_อ Yes, I was pretty sure it did (the footnote is a later addition), but didn't really have evidence to back it up.
    – yannis
    Nov 16, 2012 at 16:46
  • 1
    It also remains in the @ notifications in comments and chat. Nov 16, 2012 at 23:51
  • 3
    @yoda I know, but I don't really care about @comments and chat. Close notifications are far more visible.
    – yannis
    Nov 16, 2012 at 23:53
  • 6
    @YannisRizos It's not about what you pick and choose to care about. If you're making the case that if a user wishes to disassociate from the site for whatever reason then they should be disassociated everywhere, you should also insist on chat and comments being anonymized. Otherwise, there is no credibility to the request as it is not based on principle, but rather to serve some localized need. Nov 17, 2012 at 0:01
  • 2
    @yoda How should chat user and content removals be handled? - and there's another request for @comments that was a bit meh. Can't seem to find it now, though. Also, I don't care ;) It's the visible elements that concern me, and the principle of the request isn't so much about removing the name, as for the name to not remain on (superficially) negative actions. Someone unfamiliar with the site might think that all the user did was close and delete.
    – yannis
    Nov 17, 2012 at 0:08
  • 2
    Note that their username will persist on CW posts if they are the ones who have made the most changes there. For some reason, the displayed username on CW posts doesn't change on rename.. :/ Feb 16, 2013 at 4:41
  • 2
    Indeed, @Mr.PeanutMonopolyMcManish, see Do old usernames stick to CW posts by design? (And now this very comment also shows your December 2013 username until the end of times...!)
    – Arjan
    Dec 28, 2013 at 14:08
  • It happens on deleted questions and some comments too. See this Where can I ask questions regarding Unix programming? and a comment under the answer It is now deleted but here's an image.
    – Nog Shine
    Dec 9, 2017 at 5:29
  • 2
    I imagine that implementing this is probably necessary to satisfy the Right to Erasure requirement of the GDPR.
    – Mark Amery
    May 27, 2018 at 14:06

2 Answers 2


This is now partially completed.

First, some background. The issue had nothing to do with propagation - what you suggest was already what we were doing. The issue was the fact that when closed/reopened/deleted/undeleted events were generated for the post history, all the user's IDs and display names were stored as plain JSON in the Text column for the history event, and then never updated ever again. When a user's display name changed, we never even tried to update it in those text entries, because updating JSON in a text field in a database is hard and that's why you're not supposed to it...

This even caused oddities like this one where past display names would suddenly come back into use once the user was deleted, because the code was set to display whatever was stored when the user didn't exist, and whatever was stored happened to be whatever display name they used at the time the event was created, not at the time they were deleted.

As of now, we no longer utilize that stored display name. Instead, if the user is deleted, we just take the ID number that is stored and throw the string "user" at the front of it, generated on the fly when we display the names. This has the added benefit of working retroactively for all past occurrences, since we're doing it at the time the information is displayed, despite the cached information being different.

Now I say partially completed because these old display names still appear in the Text field and would still show up for users querying the information in Data Explorer. That's a problem for another day that we need to fix, but for now, at least they won't be displayed on the site.

* This fix does not apply to Teams and Enterprise, where we always display the user's display name even after deletion.

  • 1
    This causes a problem for account deletions prior to 2011 where the displayed username in most places would not be changed to their user code before deletion. Jun 1, 2018 at 18:09
  • 3
    Must admit, that's one of the things I've never expected to be done. Thanks a lot for fixing it, and also curious to hear why it's so different in Teams and Enterprise? Jun 1, 2018 at 18:52

I would agree with doing so, it also shows as for who proposes something on Area 51, more on that here.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .