This is also an issue affecting our organisation.

Allowing the business to manage their own customers' access without requiring an Admin is important to:

• be responsive to customer requests
• ensure access to the project is controlled

can expedite this fix for the bug.

username varies and can be very common and it's extremely difficult to differentiate.

can't expect to guess which is the correct username that is associate with the email address.

and not everyone has the ord admin role to check for the username.

Another example of an issue so easy to fix yet no one seems to care, it's just beyond ridiculous. But GIVE US MORE AI CRAP BECAUSE WE ASKED FOR IT, RIGHT?

Hi Team, 

The workaround to check for users via the User admin panel does not work for us as we are not admins, and it does not make sense to ask admin to keep checking users for my project.. We need the search user by email functionality ASAP. This is a basic search. it does not make sense that if a username exist, search by email address is disabled.  If this functionality is not implemented, this will force us to move to another platform. This is when we are thinking about upgrading our Atlassian plan. 

reference ticket with your team https://support.atlassian.com/requests/JST-994444?src=email 

How has this not been fixed in literal YEARS ???

Managing Customers is a nightmare as soon as the numbers grow beyond two figures. If the search option is so buggy could you at least disable it rather than let me use it?

Update: I don't understand how this isn't getting more votes. I've just had my team spend 10 minutes trying to find a particular email address as the user's name and the email address shared no resemblance. 

Yup, obvious flaw. Need results based on both fields. Need to find all contacts of a business = need to search by domain name, search by name = for obvious reasons.

Impacts search UI here: https://<site>.atlassian.net/jira/servicedesk/projects/<project>/customers

If however, users have changed their name in addition to having an invalid email -  for example:

email: me@email.comdonotuse //invalid TLD
name: Jane Smith

then the search string 'me@email.comdonotuse' will not have a hit. 

THIS.   The rest of that comment is BS.  If your customer only has an email address, then you can find them by searching for part of that email address.   If your customer has a name, as in that example, then you can ONLY search on parts of the name.

It doesn't matter if the email address is a bogus TLD — that is a total red herring and it is unfortunate that the OP used that which let the Atlassian go off down the garden path.   Even if you have a totally legit email address, the Name field is the only thing that is searched.

This is a ONE LINE FIX.  I am convinced that Atlassian has fired anyone who has the smallest clue about software (or even where the software is located).   ABSOLUTELY MISERABLE development process.

Thanks d3601787b40c. 33 hours does sound long, if it's causing issues for your site, I would suggest finding help at https://support.atlassian.com/.

@aknoll@atlassian.com  - currently more than 33hours. Some accounts were created through the API yesterday (8am Sydney time) and still can't be retrieved searching by email or display name now. The previous one I noted down as failing search by email was created more than 5 days ago, couldn't retrieve it 3h later and today I can find it searching by email. Not sure when the search started returning results though.

Before I've observed less 10min delay which I guess falls into eventual consistency.

Hi all, I've taken a peek around, and I believe the following is occurring:

A customer in JSD has two fields:

1. name
2. email

When a new portal customer is added, both are defaulted to their email address:

email: me@email.com
name:  me@email.com

Due to the initial design of system, the value entered into the textbox in the 'Customers' page has a validation step in the backend when the '@' is introduced:
The search on the 'email' field is disabled unless the string passes email formatting validation according to RFC1034, section 3, and RFC1123, section 2.1 . The Top Level Domains (TLDs) must match those in IANA lists. (Notably .corp is missing)

If the validation fails, then we fall-back to 'name' field lookup ONLY.
If users haven't changed their 'Full name' in the Portal Customers section in Administration, the name lookup will find them inadvertently because their default name is their email address.

If however, users have changed their name in addition to having an invalid email -  for example:

email: me@email.comdonotuse //invalid TLD
name: Jane Smith

then the search string 'me@email.comdonotuse' will not have a hit. 

Note that a search of 'me@email.com' will pass the validation check to use the 'email' field and might return the customer through fuzzy matching. 

Hi d3601787b40c, how long a delay are you seeing? We do expect some delays between the time a customer is added, and when you are able to retrieve them with a new search, due to eventual consistency in a distributed system- it can take time to propagate the update that varies with traffic.

Thanks for the additional workaround!

Is the partial workaround supposed to always work? cause I've got a few examples where it doesn't. Also is there any delays between the time a customer is created and the time it can be retrieved? It seems to always happen on recently created customers.

Another workaround (really less than ideal) is to do a JQL search for requests always raised by that email address ie reporter=mr.anderson@example.comdonotuse and get the customer id from previously raised requests.
 

This is high priority for us, is there a programmatic workaround for this we can implement today? One thought was somehow programatically downloading the entire service desk user list and performing our own search, is that possible?

This should be a high priority, it is core functionality that does not work.

Is there a workaround to this issue with regards to calling the customer search API?

It's affecting our app that retrieves users by searching for them by email address.

It's having a fairly large impact on us as we need to keep two systems in sync via this method.

Thanks.