My understanding of the state of play in v5.2 and earlier:
Saved searches with deleted users would work but you could not create a new search on a deleted user.

My understanding of the state of play in v6.0.6 and later
Saved searches with deleted users will work.
You can create a new search on deleted users in Advanced mode, but it doesn't work in simple mode because simple mode only exposes existing users in its drop-down.

Atlassian Support: there is an issue with an upgrade task added as part of fixing this bug. It's unlikely to occur but if it does, customers can either wait for 6.0.7 (where it's fixed) or you should escalate to DoS if a two-week delay is not acceptable.

The symptom is a failed upgrade task, which you'll see in the logs, with an exception beginning like this:

2013-08-07 05:30:59,146 localhost-startStop-1 ERROR      [atlassian.jira.upgrade.UpgradeManagerImpl] Exception thrown during upgrade: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:ApplicationUser][id,52900][userKey,caroline
com.atlassian.jira.exception.DataAccessException: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:ApplicationUser][id,52900][userKey,caroline][lowerUserName,caroline] (SQL Exception while executing the following:INSERT INTO a
    at com.atlassian.jira.ofbiz.DefaultOfBizDelegator.createValue(DefaultOfBizDelegator.java:379)

DoS: we believe this occurs when someone has directly manipulated the database before the upgrade and renamed a user in some places but not others. Specifically it occurs when a user's name has a trailing space in one spot and is also an assignee or reporter and has been improperly renamed (or possibly deleted, but we aren't 100% sure this will occur in that case).

We don't think this is actually likely to occur, but it's good to be prepared

I think the current compromise is acceptable. If people begin clamouring for history to work as well, then we can take a look at that then.

Tested the "reporter = deletedname" only as the "was" searches are "will not fix".

Upgrade tasks are 6104 (6.0.6) and 6137 (master). Testing should include the case where the current assignee/reporter for the issue was deleted and some other user is squatting on the username, as this should trigger the same username eviction pattern discussed in JRADEV-18718 – specifically, a deleted user with the key "fred" should get assigned the username "fred#1" if there is a user "fred" associated with another key. If "fred#1" is (bizarrely) also taken, then "fred#2" is tried, and so on.

jwinters, edalgliesh:

Adding the key mapping has the following results:

• assignee/reporter =
• assignee/reporter was
• assignee/reporter changed by
• assignee/reporter changed from
• assignee/reporter changed to

In short, adding the mappings is sufficient to fix current value searches only; history searches remain broken. Given that the search for change history values has the potential to be very expensive and that creating the mappings for those users is not adequate to fix them, mlassau recommended that we only address the current value search, which is more likely to be important. It is very useful to search for all the issues that were assigned to gsmith when she left the company and LDAP zapped her. It is less useful to search for all the issues that she ever worked on.

Is this compromise acceptable or is it essential that we fix history searching too?

Option 1 makes me feel like I need a shower, but it is certainly easier to understand and do, so I'll somehow manage to forgive myself.

Seems like the we have two choices if we want to fix this:

• Run an upgrade task to create missing userkeys for usernames in Issue assignee and reporter (don't bother with custom fields)
  or
• Completely remove the validation of usernames in searches
  The assignee text is in Lucene, its just that the validation does not think that the username is valid.
  In fact it will also try to change the "username" to a "userkey" and it would need to fallback to a no-op if this fails.

Personally I like option 1.