Redmine

Hi alone,

Deleting a user is not possible by design: what'll become the request, topic, wiki revisions made by a deleted user if it disappear? That'd mess the datas: that's why you can't delete a user.

For the translation patch, just open an issue of type "patch", indicate "translation to Norwegian against rxxxx" then just ask for the community thanks ;)

Thank you to get interest in redmine.

It might be possible to have an option to reassign those to other things. The trac migration doesn't import email addresses (sets all email addresses to username@foo.bar), but yet we can't delete the usernames so that people can use their familiar usernames, either.

Thank you for the answer, mr. Lecavelier. I will follow your guidance, and add it as a patch etc... but I didn't quite catch the ask for the community?

Regarding deleting an user - I understand that you've made this choice, and partly also why :) It's not very annoying either to have those locked users around. But it could be done. I don't know how you do this internally, but I guess if you push deleted users to another table, keeping just the FullName and union these with real users to an User collection, but then give these an overriden no-login Login, and an IsDeleted flag or property etc... I know nada about Ruby, that's for shure :) Anyway, point was: no problem for me that there's no delete.

I see Redmine evolving to the even better each day now, it's fun to watch!

If the users don't register themselves but are added by you, you may also reuse a locked test user account and change its data. However this only makes sense if the test user has not added anything like tickets or wiki pages.

i have renamed my testusers to 0001@deleted.com and suvch,,,
but mye girlfriend is asking why i'm answering this when i'm drunk, she says sheæs just aksing. anyway. a good easter to you all ;)

I understand you can't physically delete users from the database to conserve data relationships with that user, but there does need to be a flag to not display some users anywhere in the users list.

For example, what if a spam bot registers 10,000 fake users? Sure, they are all in "registered" so that they don't show in the main filter, but if someone genuinely registered it would be a pain to go through all that. And activating them all and then setting them to locked is no good because what if you lock people temporarily? You'd have to go find them in the huge list to then unlock them. There really should be a "deleted" flag along with "active" "registered" and "locked".

Just my $0.02 :)

I Agree. I have just got my first spam user account. Any updates on this topic?

Bump.

I just got my first spam as well.

Hello,

I second this idea, with medium priority. Especially, one should be able of deleting an account with review of what is linked to this user (number of wiki changes etc, listed only when willing to delete an account). Reassigning all these elements, when they exist, to some "deleted user" locked account wouldn't be a so bad idea, after all, and somewhat easy to code I guess. The "deleted user" would be created when installing Redmine, and its name localizable.

My 2 cents,

Barbara

How it's possible that there is no possibility to remove the users? Maybe from db?

Hi,
we had the same problem in our e-learning-platform and solved it by merging wiki-entries and other stuff of a deleted users to a special "unknown"-user.

You have implement that, because every individual has the right that his/her personal data will completely deleted from a server if wanted. (German law - maybe the same elsewhere)

Yours
Arne

We have several spam accounts now and frankly it makes me very nervous that one day i might accidentally click activate on one of them instead of another legitimate account.

There are literally tens of thousands of systems that have managed to delete users and have the same challenges redmine does. Arne makes an excellent point that some countries even require this. Here's what I propose:

• Admin "deletes" user.
• User's personal info is cleared.
• Username is changed to 'deleted_user_1234".
• Password is cleared.

This way all system info tied to the user is intact but the user's personal info is removed. Also, that frees up the username to be reused. If you want to get really slick you can also set it up so that if they ever return you can rename their account to what they had it as before and they can reenter their personal info, thereby retaining their old system data.

Hi everyone,

We had to do this using the console, after realizing that our test users had to go.

The users table had delete_all relationships so we were able to do this without much effort.

On the script/console:

 u = User.find(13) #change the 13 by the id of the user you want to delete 
 u.destroy

This is better than erasing the users directly on the database since some callbacks will be made.

Hi,

I'm asking myself about the same thing.
Splendeo Innovación: in wich console do you use your script ?
Is that really working on redmine ?
Thanks
Aurélien

Arne Pagel: this law stands true in other countries as well.

I'm not sure why there isn't a way to update all references to user NotAnymore to user CatchAll in the DB. we do this for our web-application after users sign a data release form...

@Aurélien Leroux:

You have to make sure you have irb installed. So, i.e. in Debian/Ubuntu:

apt-get install irb

Then go to your redmine installation root directory and proceed as follows:

host:/var/webapps/redmine# export RAILS_ENV="production" 
host:/var/webapps/redmine# script/console
>> u = User.find(USER_UID)
>> u.destroy

Here is a shorter version.
Assuming you want to delete user ids 13 and 20, type:

$ ./script/console production
>> [13,20].each { |u| User.find(u).destroy }

I it still not possible to delete users??? Gnnggnggnnn...

What are the side-effects if I delete user from irb like described here?
What will happen with the tickets / documents / wiki / forum entries attached to that user?
Will everything just disappear or will it let the DB in an inconsistent state?
Will these things be re-attached to another user?
Or what else will happen?

This is exactly the predictable thing that happens if developers do not implement such fundamental things as "delete user and reattach issues and stuff to special user" - people are starting to find workarounds that might break other things.

But there is another aspect.

Arne is totally right - this means that redmine has to be labeled as not for use in countries with privacy laws - otherwise admins in that countries might find themselves in conflict with the law, especially if they did not know about this missing feature. We have e.g. in Germany already enough problems with so-called lawyers searching your website for potential violations of laws, which then might give them the possibility to squeeze out some money of you - this happens every day and it is legal - here is one more thing for them - if they realize the issues described here every redmine install operated by germans will be a potential victim for these rats. Fantastico!

Would be fair to inform people about this serious problem on a prominent place on the redmine.org site.

Something like this:

ATTENTION: Currently it is not possible to delete users from redmine via the web interface! If you live in a country where users have the right to have their records deleted from your databases, please DO NOT USE REDMINE!

This situation is not acceptable - an easy possibility for every user of redmine to delete users and their attached data from the database must exist!

Please discuss this and consider fixing it ASAP.

Thanks for your attention,
Snaky

I have to say I disagree with the reason it would mess with data deleteing users. Surely you could just replace the deleted user with fallback users, eg the site admin. why does it matter about the particular ID or a specific that has come and gone? if user =- deleted {user admin or any other fallback ID of choice}?

Definitely should not delete the user entries... just the user personal info. We track finances in our redmine system. It's ok if the user became deleted-user-52, but they should not get completely deleted as it would completely wreck our finances.

Hi,

1. Don't delete users, we need a complete history of our projects
2. Please let me delete old users, its bad in terms of data security and old users are filling up the database

In my opinion both positions are different use cases of Redmine. Nice what people do with this tool.

So why don't make configurable?

And if one like to delete users, give their history to the system-administrator or another functional account, if not deletion can be disabled. Let deletion be disabled as default and an update would not change the behavior of Redmine and no problem will arise for any user.
This would end the discussion that is now older than 2 years and still active.

Yours
Arne

Hi Arne, I guess i'm trying to say that there's a 3rd option:

Delete user's personal info and anything that makes the system insecure, but keep the user interactions.

In general more configurations = more complexity = more bugs and harder to work with code. I'm of the perspective that options are sort of a last resort.

I have another situation...

For one reason or the other we had Redmine manage the user base. Now Redmine has been accepted organization-wide and we are integrating with Active Directory. However, the problem is that we can't have the existing Redmine users create new accounts when they log in with their AD credentials because their emails are the same.

It would be very useful to be able to migrate profiles. Guess it would go along the requests mentioned in this thread to migrate stuff users created to "anonymous" or "deleted" user and then remove the account.

What I think of doing is change the email addresses for the currently active users and then let them create new accounts with their email addresses and Active Directory usernames.

Best regards and kudos for a great product!

Would love to have the ability to delete a user mainly for the case of spam accounts. In those cases there is very little need to worry about associated things (issues, posts, etc.) since the account would never be moved beyond that "Registered" state. (at least in my case)