ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

User deletion (Feature #124)


Added by Derek Montgomery at 2011-02-02 11:00 pm. Updated at 2011-11-30 06:03 pm.


Status:Closed Start date:2011-02-02
Priority:Normal Due date:
Assignee:Felix Schäfer % Done:

0%

Category:User accounts
Target version:2.5.0
Remote issue URL: Affected version:

Description

Redmine trunk has the option to delete users on top of being able to deactivate them, this is a much needed option to deal with spambots.

(Category should be 'Users & Rights'?)


Associated revisions

Revision fc84783d
Added by Holger Just at 2011-08-02 02:26 am

[#124] Validate user status changes

Revision 54b4fdf1
Added by Holger Just at 2011-08-02 02:27 am

[#124] Allow to delete users with STATE_REGISTERED

Revision 8b7ee93f
Added by Felix Schäfer at 2011-11-25 06:48 pm

Merge pull request #124 from mbreit/bugfix/707-wiki-diff-encoding-error-ruby19

[#707] Fix encoding error on wiki diffs on Ruby 1.9

History

Updated by Holger Just at 2011-02-02 11:14 pm

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.

The implementation chosen has some flaws:
  • 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.

Updated by Derek Montgomery at 2011-02-02 11:54 pm

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

Updated by Eric Davis at 2011-02-03 01:05 am

Alexandre Nizoux wrote:

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

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). There are a lot of things we need to discuss.

(Removing from 1.1.0, there isn't a clear scope yet so we don't want to plan on this for such an early release)

  • Target version deleted (1.1.0 — Bell)
  • Category set to User accounts

Updated by Felix Schäfer at 2011-02-03 11:26 am

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 :-)

Updated by Derek Montgomery at 2011-02-03 12:47 pm

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.

Updated by Patrick Naubert at 2011-02-08 05:48 pm

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.

Updated by Ian Freeman at 2011-02-25 11:04 am

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

Updated by Ammler _ at 2011-05-20 11:57 am

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...

Updated by Felix Schäfer at 2011-05-20 12:31 pm

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.

Updated by Holger Just at 2011-08-02 12:35 am

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.

Updated by Felix Schäfer at 2011-10-03 08:42 am

Holger Just wrote:

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.

Works for me as a kludge until we have something better.

  • Status changed from Open to Ready for review

Updated by Felix Schäfer at 2011-11-13 08:28 pm

Eric, final thoughts? I'd merge this otherwise.

On a side-note: we might want to check how Redmine deletes users to cater for any database configuration that are incompatible with our own.

  • Assignee set to Eric Davis

Updated by Eric Davis at 2011-11-14 01:13 am

Felix Schäfer wrote:

Eric, final thoughts? I'd merge this otherwise.

Code in the pull request looks fine to me. Some of the controller code could be refactored but that can wait until the whole controller is refactored.

  • Assignee changed from Eric Davis to Felix Schäfer

Updated by Eric Davis at 2011-11-15 04:30 pm

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.

Updated by Felix Schäfer at 2011-11-25 05:47 pm

Reviewed and merged in 03d956c, thanks!

  • Status changed from Ready for review to Closed

Updated by Felix Schäfer at 2011-11-30 06:03 pm

  • Target version set to 2.5.0

Also available in: Atom PDF