New issue
Advanced search Search tips
Starred by 24 users

Issue metadata

Status: Released
Owner: ----
Closed: May 2015

Sign in to add a comment

user name completion not as friendly as it should be

Project Member Reported by, Nov 11 2009

Issue description

Affected Version:

What steps will reproduce the problem?
       registered_on        |    full_name     | preferred_email |
ssh_user_name | default_context | show_site_header | account_id |
contact_filed_on | use_flash_clipboard | maximum_page_size 
 2009-06-19 10:43:02.101-05 | Bar, Foo |                 | bar       |    
         10 | Y                |    1000097 |                  | Y        
          |                25
(1 row)

Type "Fo" and you will get "Bar, Foo (1000097)" and when you click add it
says the user doesn't exist. If you type "Ba" you can click on the right entry.

What is the expected output? What do you see instead?
Both cases work. It would be ideal if the search wasn't case sensitive
anymore, too.

Please provide any additional information below.


Comment 1 by, Nov 11 2009

Status: Accepted
Summary: user name completion not as friendly as it should be
What is your database?
What is the encoding you are using?
Project Member

Comment 2 by, Nov 11 2009

I've seen this bug happen when the user doesn't put in an email address.  Gerrit 
substitutes their user ID (1000097) if their email isn't available, and then gets 
confused.  Does it still put in the user ID when you type "Ba" and add the reviewer?
Project Member

Comment 3 by, Nov 11 2009

Brad, no. I'm pretty sure the user id being appended without the email is the problem.

We are using Postgres.

If you type "Ba" it shows <Foo.Bar@domain.tld> as the email address. It isn't stored
in database, but I'm assuming its pulled from LDAP.
Project Member

Comment 4 by, Nov 11 2009

It is really odd that it shows up with an email address one way, and a user id the 
other.  Is it possible there are multiple accounts?  I haven't ran into anything like 

Comment 5 by, Nov 11 2009

We never query LDAP to resolve an email address.  We're actually querying the 
account_external_ids table, which is populated off the LDAP directory during
user login if LDAP is enabled.  So look there for the entries we are trying
to match against.

The suggestion offered is the email address you matched, which is the string
in the account_external_ids table.  But when you pick the entry I think we are
switching to the preferred_email from the accounts table.  But if that is null
we insert the account_id instead.  This should explain the behavior you see.

I think the bug here is actually the same as  bug 152 , unless you are also
having issues with the completion's suggestions.

Comment 6 by, Nov 11 2009

Blockedon: 152
Project Member

Comment 7 by, Nov 11 2009

Sounds similar.

I suppose there are a couple issues here, though:
1. The autocomplete is inconsistent. Sometimes it shows email and sometimes userid
and the situations which it differs aren't intuitive.
2. Autocomplete is case sensitive on names in this case but not if they enter an
email address.
3. The userid option is not usable. I get "Foo Bar (1000097) is not a registered
user", which sounds similar to  bug 152  but with a better error message.

Comment 8 by, Nov 11 2009

Regarding 3, I think the error message just changed between when  bug 152  was opened 
and when this bug was opened.  So a retest of  bug 152  should just produce this new
better error message.

I guess the other two issues  1  & 2 are valid and aren't documented as bugs yet, so
lets keep this open for those.
I can't actually reproduce this now (1 & 2). Autocomplete seems to be doing the Right Thing all the time now and I haven't noticed any case sensitivity.
Ok, sounds like the case sensitivity can be reproduced on a Gerrit server with H2, but not on one with PostgreSQL.
Project Member

Comment 11 by, Mar 8 2011

FWIW, we still have case sensitivity with a Postgres backend.  I haven't taken the time to dig in to the problem. doesn't have any issues, so I'm not sure if it could be an encoding setting or something else..
Ok, I think we'll look into it a little, but since we're not being affected on our servers I don't think we'll be providing a fix (though if we find the problem we'll certainly let you know what it is).
Project Member

Comment 13 by, Mar 8 2011

Much appreciated!  This has been annoying at times, but not enough so to warrant any official time spent on it :(
I see that the search is case insensitive when the gerrit is hosted on mysql database.
This might be due to the default nature of the databases. I found the below at

In MySQL text columns are case insensitive by default, while in H2 they are case sensitive. However H2 supports case insensitive columns as well. To create the tables with case insensitive texts, append IGNORECASE=TRUE to the database URL (example: jdbc:h2:~/test;IGNORECASE=TRUE).

I tried with H2 database by appending ";IGNORECASE=TRUE" to the database URL, but it did not work.
One possible solution to get case insensitive results from any database is by changing search query
field LIKE %text%
UPPER(field) LIKE UPPER('%text%')

The query we are passing to GWTORM while getting account suggestions is of the format “WHERE fullName >= ? AND fullName <= ? ORDER BY fullName LIMIT ?”
I am not sure how this query can be modified into something I suggested above.

Comment 15 by, Mar 15 2011

WHERE fullName >= ? AND fullName <= ? ORDER BY fullName LIMIT ?

would become

WHERE UPPER(fullName) >= UPPER(?) AND UPPER(fullName) <= UPPER(?) ORDER BY fullName LIMIT ?
But that query could not be parsed by gwtorm and causes errors in compilation as of now.

Comment 17 by, Mar 18 2011

I'm not familiar with gwtorm. I don't see any docs online for it.  I figured that if it handled UPPER() and handled substitution by '?', that it'd work.
 Issue 900  has been merged into this issue.

Comment 19 by, Apr 8 2011

You can't use UPPER in the query because not every database supports function based indexes, which are required to efficiently implement the scan over the range of potential matches.

Comment 20 by, Apr 9 2011

Then create a second column, indexed, that has only UPPER(fullName) in it.
Project Member

Comment 21 by, May 21 2011

 Issue 777  has been merged into this issue.
Project Member

Comment 22 by, Sep 14 2011

 Issue 1128  has been merged into this issue.
Project Member

Comment 23 by, Apr 30 2015

Blockedon: -gerrit:152 gerrit:152
Improved/fixed in
Labels: FixedIn-2.11.1
Status: Submitted
Blockedon: -gerrit:152
Status: Released

Sign in to add a comment