Support deleting a user but keeping their posts


(Nathan Rijksen) #1

I just had some cleanup to do following a SSO bug (that has since been resolved), I had to delete a user which had a post but it wasn’t really relevant to delete the post as well. It’d be nice if I could either delete the user and have his posts say something like “(deleted)” for the poster or be able to reassign the users posts to a different author.


(Kane York) #2

I think a solution for this would be to reassign ownership of posts to a holder user before deleting them, like system or one that you create - e.g. this:

Unfortunately, we can’t reassign ownership of posts yet.


(Nathan Rijksen) #3

Yes that’d be ideal. With the option to choose which user the posts should be assigned to on a case-by-case basis (you could simply show a default user to ease this process).


(Kevin P. Fleming) #4

I’m curious what the value of deleting the user account is versus just disabling it so it cannot be used.


(Nathan Rijksen) #5

Deleting it clears up their username, email and SSO account(s) to be used again. In my particular use-case this was necessary as the user signed up twice with similar data causing a bug to be triggered in Discourse (which has since been resolved). The point is though that I’d want to be able to troubleshoot the issue myself rather than having to fully rely on the Discourse devs to fix it (and in this case, the fix they provided only fixed things going forward, it didnt retroactively fix the issues the bug had caused).

In an ideal setting where everything goes 100% perfectly you likely wouldn’t ever need to use this functionality, but who among us has ever been in such a situation?


(Benjamin Kampmann) #6

This sounds like a real edge case to me. I’d personally prefer the way that “disabling” vs. “deleting” is supposed to work. And as you say yourself:

Therefore I’d be against adding it. There is simply no way to anticipate everything that goes wrong and have a feature for every edge in this. It is more work to do that than fix manually the few times it happens. I’ll just quote xkcd on that:

That said, I’m happy to help you out. Here is a little script that you can copy paste into the rails console (start with bundle exec rails c from within your discourse install directory) to re-assign all posts of the soon-to-be-deleted-user to the new_user:

USERNAME_TO_BE_DELETED = "jessamyn"
NEW_USERNAME = "clay_7"
new_user = User.find_by_username(NEW_USERNAME)
old_user = User.find_by_username(USERNAME_TO_BE_DELETED)
posts = old_user.posts
topics = old_user.topics

posts.each do |post|
  post.user = new_user
  post.save()
end

topics.each do |topic|
  topic.user = new_user
  topic.save()
end

And you are safe to delete the old user. Be aware, some caches will still show the old data. Also: never copy-paste code into a production systems console that you’ve found on a forum :wink: – Code comes without any warranty.


(Nathan Rijksen) #7

This is exactly why this feature is needed. It allows you to address unforeseeable edge cases, whereas disable user does not.

Thanks for the script, I’ll bookmark is but have no need for it at this point in time. I’m simply requesting the feature because it’s inevitable that others will walk into a similar issue sooner or later.


(Sam Saffron) #8

As @riking, the feature we want is re-assign ownership, it paves the way here.


(Benjamin Kampmann) #9

Would that be one of the aforementioned “admin menu per post” features?


(Kane York) #10

I’ve gotten some of the way in here:


(Benjamin Kampmann) #11

Looks like I can’t comment on changesets before they are in a PR, will wait until then to help with the review.


(Jeff Atwood) #12

@neil also built the anonymize user function which works well for this, plus we have reassign post ownership so I consider this complete.


(Jeff Atwood) #13