We have the same issue, but the problem was the annoying emails which bounce back undelivered (sent from Administration --> Options & Setting --> Send E-mail). A workaround which I have found for this is to set their email address to "noreply@mycompany.com". This way the email doesn't get sent to their address but to this 'dead' address. If there are, say, 50 users deactivated like this (i.e. each one of them has their email set to noreply@mycompany.com, then the worst that would happen would be a single auto reply from this non-existent email address.

Benjamin, I ran into this as well a while back. I am not sure what your setup is, but if you play around with your permission scheme and the "Assignable User" permission, you can get around this and also mark users as non-active in crowd.

My integration is with AD, and I have my people in region groups. NYC, BOS, etc. These groups are the only ones that have the "Assignable User" permission. Once an employee leaves, I remove them from the region group in AD and they no longer can be assigned any issues.

I do however, need to add the old employee to crowd as a non-active user, and then I remove the user from the "jira-users" group in AD. This drops my license count by one, and allows searches on the old user.

Since some peoples left our project/company recently , this has become also major issue for us, too: To avoid that issues can be assigned to retired users we need to remove those users from Crowd.

Unfortunately this renders alls issues related to the user totally immutable. Any edit/assign/write access on issues reported or assigned to nonexisting users leads to nasty com.atlassian.jira.exception.DataAccessException: Error occurred while retrieving user with username 'xxxx'. error page. The issue cannot be handled anymore at all.

We resort in temporary recreating the user, editing reporter and assigne and re-deleting the non-existing user. But this is an annoying, time-inefficient and error-prone manual task....

to me this is a required feature - currently in 4.2.4 it is only available implicitly where the users are member of "jira-users", they can sign-on, otherwise they are rejected at login, however the user account then figures as active in the jira, and can be assigned issues to as so forth - i guess this is the general problem for all.

i use native jira user management as of 4.2.4 (enherited through several years of use though).

Thanks Derrick, seemed to do the trick for us as we do not use Crowd.

That is correct, except, if you do that, because my LDAP query in our Crowd installation does not present them to JIRA as users if they are not in the jira-users group (they effectively do not exist in crowd).

What I have done is follow these instructions (http://confluence.atlassian.com/display/CROWD/Deleting+or+Deactivating+a+User) I created another directory in crowd, added it as another directory for the jira app, added a user with the same name, email, etc and marked them as deactivated, and then in AD, removed the user from the group jira-users.

I have tested it on a user who did and did not have anything assigned to them, and the count went down, and I am still able to filter on both their names.

A bit of work to reclaim a license...

It was my understanding if you remove them from the user group "jira-users" that they would be removed from the count of users who count to your total. I took mine out of that group and created a new "jira-archived" group so that I could keep track easily of everyone who I had removed overtime. Does that work for you?

I would like to know the answer to this too. We use just Jira but are approaching our limit. A number of users are gone but the names need to remain for auditiing/tracking etc purposes.

I use Crowd to integrate with my AD. I am now nearing the limit of my license (and I have 10 users who are no longer with the company), and from what I understand, I need to keep these users in the system as jira users in order for filtering to work. These 10 users are no longer using JIRA. Is there a way to prevent them from counting towards my license limit, but not affect filtering capabilities?

The fact that it is on the short term roadmap is a good sign, but I think we need guidance from Atlassian in regards to a definition of "short term" for this specific issue. As of now there are 22 issues on their STR (http://jira.atlassian.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JIRA+and+status+%3D+%22Short+Term+Roadmap%22+order+by+votes+DESC) and this issue is the 4th most voted on feature in that list. - UPDATE: From what I can see (right now Oct 2010) there are no longer any issues in the short term roadmap.

For the responsible people at Atlassian it's obviously more important to "introduce" a new UI, than fixing issues like this one.

I created this issue seven years ago. Can you PLEASE retire my user. I don't use Jira anymore.

Oh, wait, you still can't..

Any updates from Atlassian as to when this is going to be taken care of? This seems to be a very popular issue, yet it hasn't been even assigned to any developer. Please advice.

We are also using Jira with CROWD connected to an AD. Our "user management" deactivates user for a limited time before deleting them. But at the time they are deleting the user the jira ticket is un-editable!! This is a big problem and we hope that you will give us any solution to this issue...

In house we use active directory for the main roles, passwords identical etc. However we do use externals who have a limited view on Jira, these are all temporary roles and do not have their names in Active directory, yet we cannot delete them properly if they have interacted with any ticket.

We are using crowd authenticates to Active Directory.

The problem we have is that "Temp user" come and go. Now, after the temp left, we are not able to transfer the reporter on the opened ticket to someone else. I can see potential problem ahead of us. This problem is a major issue for us. Would someone look at the resolution.

In order to deactivate a user, we are removing the user from the 'jira-users' group. We thought this was the only step required but, if the user belongs to other groups or project roles and those groups or project roles are being used in Permission Schemes to grant the 'Assignable User' role, this user will still show up in the Assignee list.

This is forcing us to remove the user from all groups and all project roles which is not too much of a problem if the user is leaving the company but if someone is going away on vacation we want to be able to deactivate and activate the account without having to setup all the user permissions from scratch when they come back.

could we bump the priority to at least "major" - this is critical for my org though

I have a classic example where delete user functionality is required. my company was part of a huge company where they were using jira globally. now, after bankruptsy of the parent company, we got xml backups of our projects from the original jira instance. now this xml containg about 10500 users while in my company there are only 250 active users.

there is no way for me to delete these 9750 users. i have to delete them manually. i have removed them from all groups (although they are not here or dont have access any more). but its very tedious to maintain 250 users in the list of 10500 users.

any quick solution is greately appreciated. or there should be a way to bulk delete users who does not have any reported/assigned issues.

This should be higher in priority as deleting a user should not be this complicated. Its a matter up just updating the database with a new user. I am sure you guys know which tables, etc. to update. I wouldn't mind running a SQL command directly in the DB to fix this. If you have one, post it here!

Thanks!

We are looking at improving user and group management as well as JIRA's use in LDAP / AD environments (JRA-1962) in a future 4.x release.

As part of this work, we will investigate this request as well.

Once I have more information regarding this subject I will update everyone.

Regards,

Brian

Although it's true that you can't set the email to blank. I've found a work around.

I have had my IT create a email account that i have access to that's internal and for my use in this situation. I do the same with Confluence.

I change their email to those accounts to that new internal email address foo@domain.com

Doing so protects in 2 ways.
1. change alert or watcher emails are sent to the void (and in our case we had external contractor that should no longer be made aware of internal issues.)
2. I had also changed their passwords, so I find out when they try to re-access and ask for a password reset, it no longer goes to them.

Need a disabled/deactivated state for users. We want to keep users who left our company in Jira for history/auditing purposes.

But we want emails to not be sent to disabled users. Even if you remove the user from all their groups, and remove them as reporter and assignee on all users they still continue to get emails for all issues where they are a watcher. And you can't search for issues a user is watching so you can't fix that. And you can't set a user's email to blank to stop the emails.

Also currently, if a user has no security roles people can still add them a watcher. Disabled users should not be selectable as watchers.

So much easier if one could just disable the user...

A disable state seems to be a good idea. The main problem here is the primary key on the username. You should have a unique id for every user. That will allow 2 or more username to coexist but only one can be active at the time.

I'll echo James Cameron's request for disabling a user. We're a large company, lots of contractors/turnover, and having all these active accounts around it not only poor security, but it can create confusion on the pick lists. Why not a disabled state that won't destroy historical data but removes them from all lists?

We create users in Crowd - and crowd authenticates to Active Directory.

The problem we have is that "external programmers" are hired for a short period in time, they get an Active Directory account from our Company and we create the users account in crowd. After the external programmer roles off - we are FORCED to remove the user, since active directory account names are being reused. We do not have any influence on the Active Directory accounts so we just remove users from crowd when they roll off.

We require also a solution which enables us to deactivate users. I guess this should be not abig deal to check while logging in if the user has deactivate/deleted flag. This must be also conidered during send mail etc. I agree that the priority needs to be moved to greater than "Minor"

Hi,
I thought that this issue should has greater priority than "Minor", this is block the usage of crowd in my compagny.
We want to use it, but in quite big compagny we can't required to change the user management of the whole compagny for having a new product.
For security and management they don't want to keep old user in the central user repository.

With implementation of great feature in JIRA 3.10 - User Picker, this issue is getting hot.
See issue JRA-13588 reported by me.

I agree with Adam Cameron - removing users from group is not a solution. We have the same situation - users come and go, and I don't want (but do it now) to on/off their group assignments.

> "...removing them from the groups that have the 'USE' permission" - what is that 'USE' permission?

It's a Global Permission (Admin -> Global Permissions).

"...removing them from the groups that have the 'USE' permission" - what is that 'USE' permission?
I look at my JIRA's (Standard Edition, Version: 3.6.5-#161) Default Permission Scheme, and can't find any permission named 'USE'?

Hi
The "remove from all groups and change password" idea is an OK band-aid but not really a solution (I'm not sure if you were proposing it as a solution). I have users that come and go (and them come back again) from projects, and whilst they're away, I want them DISABLED. When they're away, I don't want them to show up anywhere in the system (selectable user for issues, group membership, etc). When they come back, I want to re-enable them, just as they were before. I don't want to horse around setting up their groups again.

This is a pretty fundamental feature of most half-decent user-management systems I have come across.

Cheers.

I think there is a difference between a 'stale' user (no password, no groups) and a 'retired' user. Letting a user exist might lead into other troubles (like when you use an LDAP for user authentication).

For historical reasons we should not completely remove all of a users information.

The problem isn't the 'persistance' of a user, but the task oriented flow which retires him/her: I would like to be able to 'remove' a user from any activities, transferring all his outstanding activities to a 'live' user.

About the life-expectancy of Scott:
I don't want to achieve immortality through my work... I want to achieve immortality by not dying. - Woody Allen

On one of my company's vendor support sites, when a support engineer no longer works for the vendor their name shows up in reports of past resolved issues, but next to their name you see "(Inactive)". So:

Scott Farquar (Inactive)

(That would never happen, tho. ) So if the lookup of a user id fails, just show this (Inactive) flag?

Good tip about removing from groups, however - thanks Scott.

You can already 'retire' a user by resetting the password to something that isn't known, or just removing them from the groups that have the 'USE' permission.

So we should 'retire' a user?

The only caveat would be to ensure that any resolved or closed issues assigned or reported by the user to be deleted are not changed.

Just because a developer leaves my group, doesn't mean he or she didn't work on, fix, or report the bug historically.