Allow deletion of not-yet activated users, add a new "deleted user" type/class to be able to "delete" already activated accounts. Those accounts should free up the login and the mail address, though I'm a little unsure about what options the admin should have: rename the account "Bobby Bob" to "Bobby Bob (deleted)" or "Deleted user"? What gravatar do we show then? One for all deleted accounts might be confusing, keeping the mail address of the deleted user isn't an option either, maybe change it to deleted-user-24_random_chars@domain_the_installation_is_on, or maybe even @cp.org?

Just a fragment from an outsider: at least in Germany you MUST delete personal data, like the name or e-mail address of a user, if he or she requests it. So it'll be nice to have an option implemented that allows an admin to set a user-account/e-mail-address to something completely generic like 'deleted_user' (or deleted_user_randomchars) - "Bobby Bob (deleted)" wouldn't be an option for that purpose.

One additional thought: it'll be probably good, not to set invalid e-mail-addresses - better allow the delete function to set no e-mail at all and make sure, the rest of Chiliproject doesn't try to send mail to deleted users - otherwise you'll probably get an increasing lot of rubbish on the mail server over time ;-).#

Another idea would be, to allow the admin to choose between several options how deleted accounts should be handled - but of cause allowing options is always more work to do for the developer ;-).

Jan Sellmann wrote:

Another idea would be, to allow the admin to choose between several options how deleted accounts should be handled

That's what I meant: Give the choice to keep the name of the deleted user in the "new name" or not, and so on.

I thinking there would be two options:

• delete - keeps the user record and their data but changes their account (e.g. email, login, names change or are hidden). Deleted users could be re-added provided they don't clash with any other users (e.g. someone else used their login while they were deleted).
• destroy - purges the user records and reassigns their data (this is what Redmine does)

This way the Administrator can decide how to handle each account on a case by case business.

• old employee => delete
• spam user => destroy
• German law request => destroy

Another idea I had was maybe we can "hide" some data. So if you delete "Bobby Bob" that account would appear as "Deleted User" to everyone except admins who will see them as "Deleted User (Bobby Bob)".

Eric Davis

Eric Davis wrote:

• destroy - purges the user records and reassigns their data (this is what Redmine does)

I still think this will create more problems than solve. For example: how do you handle data created by plugins? I wouldn't want to force any column name on plugin creators. I still think activated users (non-activated users can safely be deleted) should be anonymized to the degree required by the admin/law, everything else is more work than needed.

• German law request => destroy

Deleting person-related data (name, email address, login name, …) is enough and AFAIK the only thing a user can request.

Another idea I had was maybe we can "hide" some data. So if you delete "Bobby Bob" that account would appear as "Deleted User" to everyone except admins who will see them as "Deleted User (Bobby Bob)".

Might be an option, but "hiding" data is not enough everywhere :-)

I'm traveling to Finnlabs next week, I think Holger and I could spare an afternoon/evening to tackle that one.

Personally I won't use destroy unless it is a spam account and I'm in the US so delete should be fine. I think as long as we can remove (or provide a way for an admin to remove) personal data to comply with German laws, then that + delete would be good enough.

Eric Davis

hi,

we want to use Chili for our studies and every semester, hundreds of studies goes and comes. So I need a way, to delete everything, from the project till the complete user. Otherwise diskspace and database grows very fast in a few months. The authentication runs over LDAP. If the user isn't found in the LDAP tree anymore ... I have to cleanup everything.

cu denny

An alternative to anonimize an account is to pass identification information to an one-way hash, that, for example, if the user decides to "undelete" their account, you still be able to figure out what it was.
something like: sha256(salt+email) would be a good start.

Also considering the German law case, it's clear that we shall have more then one alternative, perhaps configurable on site admin options.
1- Flag account as deleted and anonymise it (should maintain data integrity and help recover account)
2- Immediately destroy user model and reassigns to other user. (there shall be an internal "anonimous" account that can be assigned by default, when reassigns to other users doesn't make too much sense, for example, in case of ownership attribution, as you can't attribute ownership to someone that, that someone hasn't been the owner of, that includes texts, comments and so on).

is there a ticket for this?

Wow as a DBA I think I have to put my two US cents in here!

So in Germany when a user requests to remove all their personal information do they do that for accounting/payroll systems at the user's request? Historically, recording keeping would be a nightmare for taxes in the US. I can just hear that conversation between the company and the IRS. "Well sir, we paid $120,000 to Deleted User!"

Well my vote is for an isDeleted column in the table. Data integrity stays in place and if the user comes back the admin can just remove the check for isDeleted. I really don't think what displays for the name is a big deal whether it's the real name or whether its (Deleted User - 127).

IANAL: but obviously above stated requirements about German privacy laws are simplifications. If it's a vital part of your business, related to taxes or paychecks,... then you'd have to keep the data of 'Deleted User' in your records. Is it vital that User Y reported a bug in your project? Or is the information in the bug relevant? You can even record Jan Sellmans data for eternity, with a flag 'doesn't want to be in our records'. A possible workflow:

• User's personal data (eg. preferences, tokens, private queries...) should be deleted, public data (eg. issues, wiki edits, attachments...) are reassigned to the anonymous user.
• For spam users and accounts that aren't activated a much more simple purge should be possible.

hi,

at now, we have 1200 users :-) with round about ~2463 projects (rows in projects) in Chili 3.5.0. How should I handle delete users and projects? I don't want to keep anything so I would prefer:

Delete unknown users:

1. Compare registered users and users on LDAP
2. Delete unknown users and his projects (username, username-project1, username-project2 ....)

Handle old projects:

1. If user exists:
   1. Find (6 months>) inactive projects and archive them
   2. Find (12 months>) inactive projects and delete them

My problem:

If student1 created a project-foo and added student2 as a project member, student2 can write tickets, wiki pages and so on. What happens, if student2 was deleted? The opposite, shouldn't be a problem, because all references are deleted too, if the project was deleted or archived.

So maybe a better solution could be, to rename the users delete-<longid>, clear all preferences (mail, web, wiki ...), delete his projects and keep him, until there is no references to other projects anymore, than destroy should be fine.

The first one, what is interesting for me, how can I find old projects and and archive them automatically (in Ruby, not DB directly) ? I think, I have to take also a look on SVN/Git (scm plugin) activities and what should I use? (projects: updated_on && users: last_login_on ?).

cu denny