- SonarQube Enterprise Edition Version 8.9.1 (build 44547)
- Azure AD Authentication Plugin, single-tenant, login same as AAD, no group synchronization
- I am trying to search users in a case-insensitive fashion via the web-api.
- So far, I have tried using the user-groups/users endpoint and the users/search endpoint. Some of our users’ email addresses are init-capped while others are lowercase. The init-capped ones aren’t found when searching for the email address.
Since the logins created aren’t guessable, I am trying to use the email address to find the login for a particular user. But the search appears to be case-sensitive. This seems odd, since email addresses are not generally case-sensitive. Am I doing something wrong?
First of all, welcome to the community!
The search of API api/users/search?q=<search_string> has the following logic:
- If the passed parameter <search_string> is equal or shorter than 15 characters the search is partial and case-insensitive.
- If the parameter is longer than 15 characters the search is exact (and case-sensitive).
As email addresses are typically longer than 15 characters the search by email address is almost always exact and case-sensitive.
One important thing to keep in mind is that the email addresses of the SonarQube users coming from an external identity provider are registered exactly as they are passed from the provider. It is not possible to update them manually in SonarQube because they are synchronized and updated every time a user logs in.
What might help in your case is to use external identity provider(i.e. AAD) to look-up the user email (the provider should allow full, detailed, case-insensitive search by email) and once the email is returned it can be used to look-up SonarQube users having this email with api/users/search?q=. This will work because email in SonarQube is registered exactly as it comes from external identity provider.
SonarQube capabilities to search for user entries are primarily limited to exact case-sensitive search. For a more detailed search with more features external identity provider should be used.