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.

If you use Ians workaround, remember to use the same email when re-creating the user in eg crowd.

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.