I suppose one workaround would be to rename it and give it to someone else who wants an account...
The short answer is that there's no current way to delete it. I recognize that this kinda sucks, but I haven't really come up with a solution that I love. I think the policy implied in the message makes sense: no orphaned revisions. So, to be able to delete an account, you kind of need to be able to wipe the revisions away, and really you only want admins to be able to do that.
I guess theoretically there are two ways to do this now:
1. /admin/empty_trash will get rid of all trashed cards and all their revisions, so if you delete all cards revised by this user, this would work (but it would completely delete everything else in the trash, too)
2. /admin/delete_old_revisions deletes all old revisions of EVERY card, including ones that aren't in the trash. So this would work so long as the user in question wasn't responsible for any *current* card revisions. But this one has even more dramatic side effects than #1, because it basically wipes the history of every card you have.
I guess a better solution would let admins selectively delete all of a single user's revisions, provided none of them were current.
Not sure I'm communicating super clearly today; does any of that make sense?
Another possible solution is an admin feature to give a user's edits to a different account. In the use case stated, the edits could be moved to the new account. For other cases, you could give them to a card (doesn't even need an account, right?) created for this purpose ("Removed User" or something like that).
I like Gerry's solution.
I like it too but that user has a history of how and when they edited everything. As people leave the site it turns into a ghost town of "Removed User" edits and so on.
It would be nice to mark the user as inactive. He can't log in or edit... and his card is added to some graveyard of removed users that people can't access. You could reactivate the account if needed. What do you think?
This is coming up fairly frequently lately.
There certainly are cases where, for legal reasons or disk space or whatever other rationale, we need to be able to delete data permanently. (Eg specific revisions with sensitive information). In such cases, even the trash is not "deleted enough". But I would not consider this a best practice, and in this particular instance we can't (currently) put the cards in the trash.
In general, I find it much more desirable to make something deleted *from the perspective on non-administrators*, which is largely Mir S.'s solution. You can basically do all of that now. If you can make it so the card can only be read by an administrator, and you block the account, then this is largely the solution described. The name still shows up in histories, but if you click on it you will see that you're denied permission to read the page. (You can also change the name of the card to get it out of the way).
One reason this solution was unsatisfactory before was that the email itself would remain in the users table and block creation of a new account with that email. And there was no interface to fix it.
With the 1.13 code, the biggest change is that all information, including user details, is in cards, so administrators will have access to manage all this stuff directly.
I like this kind of things as a best practice, but I suspect some folks will continue to be frustrated by the inability to remove a user completely. So it becomes an issue of whether we'd rather try to explain the rationale or deal with edit history ugliness.
Getting really excited about this 1.13 release. When do you presume it'll the light of day?
Well, there are "pre-releases" available on rubygems.org, the code is in the develop branch on github, and at least one site (wikirate.org) is already using that code. The hold-up is that there is some account-related functionality that wikirate.org does not use but many other wagn sites do that I still need to finish restoring, but I've been struggling to carve out time to do it. Meanwhile other new functionality keeps coming in that we need to push out to wikirate.org.
I *really* want to polish that off this week, but it's touch to guarantee that I'll get it done.
I'm confident that once this comes out we'll go back to frequent point releases. There's nothing as challenging as this account migration coming up before 2.0.