Project

General

Profile

Actions

Feature #1572

open

Delete Users and automatically ticket change

Added by Guest Test almost 16 years ago. Updated over 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Accounts / authentication
Target version:
-
Start date:
2008-07-03
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

1) In order to free the username for other users administrators should be allowed to find inactive users and delete them.

2) Normal users should be allowed to deactivate their own account.
2.1) New issues can't be accidently assigned to unactive members. This will prevent email spam for users, who have quit to work on a project, but are still registred on the site.

3) To boost flexibility registred users should also be allowed to delete their own account. 3.1) All unclosed issues of deleted users will change to the default pause status e.g. "On-Hold".


Related issues

Related to Redmine - Feature #7296: Ability for admin to delete usersClosed2011-01-11

Actions
Has duplicate Redmine - Feature #4765: Remove userClosed2010-02-08

Actions
Actions #1

Updated by Thomas Lecavelier over 15 years ago

  • Assignee deleted (Jean-Philippe Lang)
  • Target version deleted (0.8)

The target version field has to be set when it will actually part of the target release.

Actions #2

Updated by Chris Miller over 15 years ago

  • Target version set to 0.9.0

Thomas Lecavelier wrote:

The target version field has to be set when it will actually part of the target release.

I see no reason this can't be done in 0.9. It's really needed - right now the only way to truly obliterate the trace of bots that have registered themselves is to go through the SQL database yourself - not fun.

Actions #3

Updated by Chris Miller over 15 years ago

Just for your information so you can work around it, I figured out a few SQL queries to help you manually delete people from your database (MySQL). This is best done from a shell.

Get a list of all users and their ID. I suggest you delete by ID, since that's far less likely to mess things up.

SELECT id, login FROM users;

Test the ID just to be sure, otherwise you could accidentally delete the wrong user!

SELECT id, login FROM users WHERE id = #;

Finally, be careful when you do this!

DELETE FROM users WHERE id = #;

Actions #4

Updated by Jean-Philippe Lang over 15 years ago

  • Target version deleted (0.9.0)
Actions #5

Updated by colin moock about 15 years ago

+1

Actions #6

Updated by colin moock about 15 years ago

sorry, that previous comment should have been:
+1 (killing spam users is an important issue for us)

is there a way to edit your own comment?

Actions #7

Updated by Antoine Beaupré about 14 years ago

Just clearing up the user table may not be a good idea, if the user has been in use for a while. There are entries keyed on the userid in a bunch of other tables.

If the user has not logged in or did anything, the following tables need to be cleared:

  • tokens (user_id)
  • user_preferences (user_id)

On top of that, a user id may also be found in the following tables:

  • attachements (author_id)
  • changesets (user_id)
  • groups_users (user_id)
  • issues (assigned_to_id, author_id)
  • issue_category (assigned_to_id)
  • journals (user_id)
  • members (user_id)
  • member_roles (member_id)
  • messages (author_id)
  • news (author_id)
  • queries (user_id)
  • time_entries (user_id)
  • watchers
  • wiki_contents (author_id)
  • wiki_content_versions (author_id)

Looks like it would be quite messy to cleanup all this stuff. For example: what do we do with an issue owned by a deleted user? Do we revert back to anonymous?

I'm not sure that deleting the users is a good idea.

Actions #8

Updated by colin moock about 14 years ago

"I'm not sure that deleting the users is a good idea."
--
please don't let implementation considerations obscure the actual issue here: spam bots are registering users in redmine projects all over the world, and redmine owners have no way to delete them. we have over 100 spam users in our db now. we need a way to delete them.

Actions #9

Updated by Eric Cope about 14 years ago

If assigned tasks, etc. are the only issue, a step for deleting users should be to reassign all related data to another user, an administrator for example.

Actions #10

Updated by Ben Blanco almost 14 years ago

+1 We have the same problem, and have been manually cleaning the SQL DB since 0.7x

Maybe this could be split into two mini-features:

  1. Add Delete choice to the Registered page view (today the only option remains: Activate)
  2. Add Delete + Reassign Issues/Wiki edits/etc... on the Locked page view

In this case, the higher priority, and likely easier to do, would be on the Registered page.

Actions #11

Updated by Ivan Zotov almost 14 years ago

Deleting users ( simply from DB ) works normal. Issues change field "assigned to" to "---".

Actions #12

Updated by Ivan Zotov almost 14 years ago

In shotgun software it is works same. ( shotgunsoftware.com )

Actions #13

Updated by Mark Anderson about 13 years ago

Ben Blanco wrote:

+1 We have the same problem, and have been manually cleaning the SQL DB since 0.7x

Maybe this could be split into two mini-features:

  1. Add Delete choice to the Registered page view (today the only option remains: Activate)
  2. Add Delete + Reassign Issues/Wiki edits/etc... on the Locked page view

In this case, the higher priority, and likely easier to do, would be on the Registered page.

+! at least for a bogus registered user - they have left no traces in the DB yet.
Mark

Actions #14

Updated by Anonymous over 9 years ago

FYI - you can put this in cron and it'll lock any accounts older than two months.

psql redmine -c "UPDATE users SET status = 3 WHERE last_login_on BETWEEN '2000-01-01' and '$(date +%Y-%m-%d --date="2 months ago")' and status != 3;" 
Actions

Also available in: Atom PDF