Agreed. Pathetic.

Pathetic.

Closing as duplicate.

"Deactivate User" is covered by JRA-3774 and should be resolved in v5.1

The "assign to other user" is already possible using a search and bulk edit.

You shouldn't use the original email assigned to the deactivated user. Else, JIRA will receive an NDR from your mailserver, as the mailbox no longer exists, should any updates be applied to tickets owned by the deactivated user.

Instead, I would set the Crowd account to use the manager's email. That way they get informed about any changes to tickets formerly owned by the deactivated user.

We are experiencing the same issue, but do have a "workaround":
1. Select 'Directories'

• 'Add Directory' and choose 'Internal'
• Name 'Disabled/Expired Accounts' and leave all other options defaulted
• Permissions tab options are left at defaults
  2. Select 'Applications' and edit your Jira entry
• Add the new Group you just created to the bottom of the list and allow it to authenticate
  3. Select 'Users' > 'Add User'
• Use the email account for their manager/supervisor so they are updated to any changes
• 'Username', 'First Name', 'Last Name' equals what their Active Directory username was
• Set an uber complex password so that no one but you will know it. Put it in a password vault if you have one (ie. KeePass)
• Ensure to assign them to the Directory you created in Step 1.
• No Groups or Roles are assigned to the account, as we simply need them to have the ability to be authenticated using Step 2. Otherwise Jira gets confused and throws the stack trace errors whenever someone tries to do anything with their tickets.

From that point you can decide then to:
A. Perform bulk moves on their Jira issues
B. Reassign individual issues to other active persons
C. Perform edits on their Jira issues
D. 'Status Quo' and leave the issues as they are until action can be taken to clean things up

You can choose to either leave the account within the Crowd database or remove it. Because we set uber complex passwords for these accounts we choose to leave them within the Crowd database.

I hope this workaround can help others in the same situation until Atlassian decides to actually fix the problem.

+1.. and I can't believe this issue hasn't been fixed in 6 years!

We're also using Crowd. Just fix the darn problem (here or in CWD-202).

I posted a similar scenario on Atlassian Forums, and was referred to this issue - http://forums.atlassian.com/thread.jspa?messageID=257291702&#257291702

The suggested workaround seems similar to what Ian Daniel posted. I found that in order to properly clean up the inactive user account was to manually edit the JIRA database and change the assignee/reporter for open tickets to another account.

CWD-202 links to this issue, claiming that it is the issue for the fact that JIRA doesn't cope when a user is removed from Crowd or from the underlying LDAP repository. Is this one really the issue? This issue has more to it than just the fact that JIRA throws exceptions when it accesses a user who is no longer in the Crowd repository. We should have a dedicated issue for just the "missing user" issue.

Updated the priority - when issued 5 years back it could be handled. Nowadays integration with Crowd and having a much larger install base it cannot be seen as a minor issue anymore...

What if you are managing 10,000 users and the corporate I/T policy is to disable the accounts to all applications including crowd cannot see them?

I think it is premature to close this issue if Atlassian wants to attract larger install bases.

It is really disappointing to see this issue is low priority citing a workaround that would require changing a world wide I/T policy should anyone wish to use Atlassian software.

Agree that it needs to be possible to inactivate users. I would like inactivated users to still be able to have issues assigned to them (i.e. issues that they were assigned while active users) - this may be useful if you go back to a closed issue, and wonder who worked at it last.

Workaround

If you have deleted users from Crowd, and those users are assignees on issues in JIRA, you will get DataAccessExceptions in JIRA. JIRA will not let you re-assign any issues for which the deleted user is the assignee, because of the DataAccessExceptions.

The fix is to re-create the user in Crowd. Then you can re-assign the issue, as the exception will not be thrown.

You can then deactivate the unwanted user (better to deactivate than delete).

I would like to extend this a bit:
We are using CROWD and an AD forest. That means that users come and go and we have little control (and process) over this as it's globally distributed and local policies vary and sysadmins come and go. This leaves us with users & tickets in JIRA which are not backed by the underlying user store (being CROWD ie AD in this case) and this seems to break a few things in JIRA. For once it breaks the user-pickers.
What I would like to see is some kind of clean-up job that put's JIRA back in a state where it at least works normally.

+1

Atlassian: Any plans for this (and other user management related like JRA-2220/JRA-964).
I have been using Jira for 4 years now and the number of 'inactive' users grows and grows. I would really like to be able to manage this properly.

I too have encountered this problem. All companies - all groups of any kind - have SOME turnover, and as time progresses obsolete user accounts will gather in the system. These can never be deleted because, as has been said, they may have reported issues and logged work on issues (we should retain a record of this, even after the user leaves the company).

There are two key pieces I'd like to see for this feature:

1. Disabled user accounts NEVER receive email (aside from a notification that their account has been disabled).

2. Disabled user accounts are invisible for the most part. They should not appear in any list of users. Even on the User Browser under Administration, disabled accounts should only be shown if an option to do so is selected (as part of the filter). Disabled users should only be shown where they had previously been selected.

I realize this feature isn't high priority, but hopefully it'll be implemented this decade.

Good idea, although we do have anonymous read access enabled, and I think there would be organizational resistance to changing that.

I assume that's what you mean, right? I could make it so only jira-users could browse, and while that would fix the email issue, it would prevent anonymous viewing.

Daniel - I assume your site allows Browse permission to 'Anyone'? Otherwise, if a user is not a member of any groups, then they will not have Browse permission to see the issue, and therefore JIRA will not send out e-mails to them since it knows they can't see the issue.

Removing from jira-users and reassigning issues is NOT sufficient. The user could still be a watcher or reporter, and emails will be sent. Since you can't put in a blank email address, JIRA will send an email to dead account, which will probably bounce, and JIRA will treat the bounce as an email (JRA-11074)

If anyone has a workaround, I would love to know what it is.

addition to the above:

• he is no longer selectable at the "watcher list"

I think the User should not be deleted but only declared "invalid". That means:

• he is no longer selectable at the "assign to" list
• he can no longer login
• he stays as reporter and commenter
• the issues where he is assigned should be assigned to a specific user

Yes & No. My wish is:
1. The Assignee should be set to none when the issue is closed (this is currently not possible in bulk edit, while it should).
2. The Assignee should be set to a preferred user for issues holding another status.
3. Reported issues by the user-to-be-deleted should keep there current reporter!
4. The user should not have any account in JIRA anymore.

This shoul be quite easy with bulk edit.
Should we redirect the user to bulk edit and then return to the "view user" screen?