Hugh, I was doing a similar thing with the email address, changing it to a junk email address I have within the company so I can at least see if someone tried to reset the password and the like.

Another option is to change the top level domain in the email address to .invalid, this is the official RFC way to do it.
i.e. joe.user@mycompany.com becomes joe.user@mycompany.invalid

This based on the O'Reilly Jira Admin book will prevent bounce errors from appearing the Jira logs.

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?