| Issue 321: | user name completion not as friendly as it should be | |
| 24 people starred this issue and may be notified of changes. | Back to list |
Affected Version:
Environment:
2.0.24
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.
Nov 10, 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?
Nov 10, 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.
Nov 10, 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 this.
Nov 10, 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.
Nov 10, 2009
(No comment was entered for this change.)
Blockedon:
152
Nov 10, 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.
Nov 10, 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.
Mar 8, 2011
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.
Mar 8, 2011
Ok, sounds like the case sensitivity can be reproduced on a Gerrit server with H2, but not on one with PostgreSQL.
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. r.android.com doesn't have any issues, so I'm not sure if it could be an encoding setting or something else..
Mar 8, 2011
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).
Mar 8, 2011
Much appreciated! This has been annoying at times, but not enough so to warrant any official time spent on it :(
Mar 15, 2011
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 http://www.h2database.com/html/features.html 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% to 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.
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 ?
Mar 18, 2011
But that query could not be parsed by gwtorm and causes errors in compilation as of now.
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.
Apr 8, 2011
Issue 900 has been merged into this issue.
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.
Apr 8, 2011
Then create a second column, indexed, that has only UPPER(fullName) in it.
May 20, 2011
Issue 777 has been merged into this issue.
Sep 14, 2011
Issue 1128 has been merged into this issue.
Apr 30, 2015
Improved/fixed in https://gerrit-review.googlesource.com/67570
Blockedon:
-gerrit:152 gerrit:152
May 7, 2015
(No comment was entered for this change.)
Status:
Submitted
Labels: FixedIn-2.11.1
May 7, 2015
(No comment was entered for this change.)
Blockedon:
-gerrit:152
Jun 21, 2015
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |
Status: Accepted