User deletion (Feature #124)

While this feature was one of the more often requested ones on Redmine, it is rather difficult to get right. That was probably the reason why it didn't got implemented for that long.

• It tries to has all those places where Users are seemingly referenced hardcoded in a method. That makes it hard for plugins to detect that (and is probably going to break many installations with unaware plugins installed)
• Activity of the to-be-deleted user is always assigned to anonymous. But this is not what you want most of the time. With that implementation, you can't track issue changes, booked time entries, ... after the deletion.

The last point is actually the trickiest. There are different possible things to do. Some data-retention laws require user-data to be completely removable on request. This could mean Redmine's approach (but hasn't to, IANAL). In closed corporate environments on the other hand, most often you'd want my described behavior.

Also, (data-retention laws aside) it isn't really clear to my why you'd want to delete users. The don't cost much. If you'd just have a way to "recycle" mail addresses and logins, you'd probably be just fine with letting them live there alone. And it would save us all that hassle of having to find all references to a user id and having to appropriately deal with them.

What about a special 'Deleted user' instead of anonymous that could be like a regular user, only gathering all activities from deleted users?

Eric Davis wrote:

That's what I was thinking too. Maybe even keep the old user around but change their name to "Deleted - Eric Davis" so you have the historic data but they can't login (and the email/login can be reused on another account).

"Separate" user class: definitely, and would be the "easiest" to make sure nothing goes awry anywhere down the line. The name (or name change rule) should be configurable though, still having the "original" name in the name of the deleted user might not be enough for some legislations to consider the user information to be deleted. The gravatar must be taken into account too: replace all with a custom gravatar? Just keep the hash of the mail address and change the gravatar links thus that they show only the "default" gravatar, not the user-selected one? That could be used to track the original gravatar though and might give away who the user was. Or download the default gravatar, anonymize it and use it? And so on :-)

Felix Schäfer wrote:

The name (or name change rule) should be configurable though, still having the "original" name in the name of the deleted user might not be enough for some legislations to consider the user information to be deleted.

Totally agree on this.

As for the gravatar, I think a generic "deleted user" icon should be used, eventually allowing admin to specify which icon he wants to use for that.

For IRCan, the requirement was to have a way via the GUI to delete registrations that were obviously spam accounts. I ended up creating a Rake task, but it has no UI hooks, so my admins cannot use it themsleves.

Felix Schäfer wrote:

still having the "original" name in the name of the deleted user might not be enough for some legislations to consider the user information to be deleted.

Agreed. Make this configurable by the admin. Either Deleted - First LastName or Deleted - User 12200896

I don't see the difference from that renaming to locking. I would also say, deletion of regular users isn't needed, but deletion of spamers should, and those should be deleted completely, with all related tickets, wikipages, forum posts etc...

Ammler _ wrote:

I don't see the difference from that renaming to locking.

Locking: all person related information is still in the DB and the login is still "in use". Deletion through "renaming": the login is released, and you can remove person related information.

On https://github.com/chiliproject/chiliproject/pull/90 I have sent a pull request to allow the deletion of registered users. This solves the simplest part of the problem.

The patch does two things:

1. It enforces the workflow of User statuses via validations (esp. that no active or locked user can ever become registered anymore)
2. Allow to delete registered users.

This happens under the assumption that registered (i.e. not active) users didn't do anything in the system yet and thus have no references anywhere. This assumption is true in the core ChiliProject currently.

FYI: I might be starting on a similar feature for a client. We are going to use cron to delete registered users so I might be able to release that code to automate this process a bit too. Shouldn't affect the acceptance or code in this issue though.