actual results: List users with login name real name user id matching expected results: include a fourth option that lets me search for either login name or real name (this is sorta what completion uses, why should edit users be less featured than completion?)

What's the relation with Bug 63689 ?

Let's just put the autocomplete into that search box when that option is enabled, and make it the default one. :)

Oh yeah, I'm surprised autocomplete isn't already there!

I've implemented this feature. I included two sets of input fields. More than two (i.e. three) sets will make the logical comparisons (AND/OR operations) somewhat complicated and useless. I've called trick_taint on $query in editusers.cgi. I'm not sure if this is really a secure thing. Please have a look at it.

This patch corrects a minor error in JavaScript code of the previous patch.

Comment on attachment 613522 [details] [diff] [review] A patch implementing the feature request - v2 Wow, no, we don't want this complexity. What we suggested in the previous comments is to reuse the autocomplete code which we already have. You don't need all these code changes at all. See how the autocomplete code works when viewing a bug report.

So you mean the autocomplete used when we want to specify a reviewer, right?

(In reply to Koosha Khajeh Moogahi from comment #7) > So you mean the autocomplete used when we want to specify a reviewer, right? Yes. It's the same code as for the assignee, QA contact and the CC list.

I removed the 'p' tag because it causes the elements not to appear in a single row. Would that be OK?

Comment on attachment 616585 [details] [diff] [review] user autocomplete >-<label for="matchstr">matching</label> >+<label for="matchstr">matching </label> Revert this change. If you need a whitespace after the label, this must be done this way: >+[% INCLUDE global/userselect.html.tmpl ... append a "+" sign right after [% to add a whitespace. This means: [%+ INCLUDE ... %]. >-<input type="submit" id="search" value="Search" /></p> >+<input type="submit" id="search" value="Search" /> While you are on it, please remove the trailing whitespace and the /. Bugzilla uses HTML4.01, not XHTML. I don't know if you tested your patch, but if the select field is set to "real name" and you type a real name which matches something, and you select one of the suggested user accounts, then the email address is copied into the field and so the search won't return anything. I'm not sure how to fix this problem. Maybe we should add a new item to the select list named "real name or login name" and only enable auto-completion in that case (if this can easily be done). Or we could also use JavaScript to automatically set the select list to "login name" when the admin selects something from the suggested list.

> I don't know if you tested your patch, but if the select field is set to > "real name" and you type a real name which matches something, and you select > one of the suggested user accounts, then the email address is copied into > the field and so the search won't return anything. I'm not sure how to fix > this problem. Maybe we should add a new item to the select list named "real > name or login name" and only enable auto-completion in that case (if this > can easily be done). Or we could also use JavaScript to automatically set > the select list to "login name" when the admin selects something from the > suggested list. I think the second choice is preferable. If the admin is looking for a certain user using his real name then in case of a match he most likely doesn't care about the selected item on the select element. The auto-completion is used just to facilitate searching. What do you think?

This should do it.

If the admin is entering a user ID, the auto-completion code should not be triggered, though.

We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.