I can't believe this bug isn't already filed. We should have an auto-complete drop-down for the assigned_to, qa_contact, cc, and requestee fields that uses XML-RPC or JSON-RPC to get the names of users. We already have the necessary WebService function, User.get, and all we need to do is implement the client side. Performance should be taken somewhat into account, only in the sense of "let's try to avoid overwhelming the server", but usability is the most important concern. Note that Everything Solved wrote some code that does this that we could possibly re-use parts of.
Created attachment 412782 [details] [diff] [review] Work In Progress
We no longer accept new features for Bugzilla 3.6. Retargetting to 3.8.
Created attachment 427739 [details] [diff] [review] V1 Here is my version of the Work In Progress. It works really well. However... to implement this I had to edit userselect.html.tmpl which is basically used all over the place but i only added the JS and CSS to the edit bug pages. It would be easy to copy the css/js includes to multiple places or just include them in global (which i don't recommend). mkanat and others take a look at the patch and let me know what you guys think. btw. wow it was easy to do this!
after thinking this over i'm not sure if i should have added the autocomplete to userselect.html.tmpl. I could have just done it on edit/create. what is better? Adding autocomplete everywhere userselect is or just on edit/create? Do we add this to the flag UI as well?
something i just noticed with this. the @ sign gets converted to %40 by the YUI json stringify and then the backend throws an error. Do we not want it to convert the %40's and other encode characters or is this a bug in the webservice?
I'm not sure we should add autocomplete for the requestee field without being able to pass in the flag information. Otherwise we'll introduce another complication to the user. The UI will encourage them to fill in the autocomplete with a full name which might not have authority to set the flag. This could be especially frustrating for when a user has 2 emails for bugzilla (i'm looking at you BMO folks!) ;).
If you show the "real name" field in addition to the email address, the ambiguity shouldn't be a problem.
Oh, also, you'll also have to either check feature_enabled('jsonrpc') or make all the json-rpc stuff into required modules.
Created attachment 427983 [details] [diff] [review] v2
Please fix the indentation in default/global/userselect.html.tmpl, especially for <input> which should be vertically aligned with the previous [% END %] and the 2nd [% IF %] block where the indentation is totally confusing. Especially, its corresponding [% END %] should be aligned with [% IF %].
nits fixed. not bothering to repost until i get further fixes, but I'll repost it if that's the only thing you want me to fix.
Created attachment 427987 [details] [diff] [review] v3
Created attachment 427995 [details] [diff] [review] v5 added all the stuff necessary to get this to work in all the UIs that use userselect.html.tmpl
please note we should make sure the down arrow autocomplete still works for those pros who love it. Not sure how we do that thought
removing requestee from the title since that requires webservices we don't have yet.
Created attachment 428024 [details] [diff] [review] V6 hopefully the last version. Cleaned up some stuff and also moved the inline css from show_bug.css to global.css since there are at least 3 other UI's that use the userselect.html.tmpl stuff. I added more comments, set the query throttle to 0.05 and tried to address anything that was left. Basically if mkanat r+'s this we can check this puppy in i think. I also noticed that the keyword autocomplete is already on keywords for BMO and i guess people like it so I'm going to assume they'll like this one as well.
I was testing this fix and it turns out it still doesn't work because if you go to the edit component page this doesn't work. I'm tempted to move the autocomplete into the rollup what do you think max?
Created attachment 428031 [details] [diff] [review] v7 after some testing it looks like adding this capability to some pages (specifically the edit component page) is more trouble than it is worth. So instead I made sure that if the JS required to generate the autocomplete isn't on the page the user does not see any errors instead it just skips it. i use the same technique I use for the console. for those playing along at home this still adds the autocomplete to the edit/create and edit multiple UIs just not any of the admin UIs
(In reply to comment #26) > after some testing it looks like adding this capability to some pages > (specifically the edit component page) is more trouble than it is worth. What's the problem with adding/editing components? Why is it harder?
There is some strange layout issue with tables (i can post a screen shot). I will investigate it further if that is desired. The other problem is that I would have to include fields.js on the edit components page or move it to somewhere else and including fields.js seemed like a lot for just 1 thing. I'll start working on it and have a patch ready if you guys would like me to add it.
Created attachment 428071 [details] [diff] [review] V9 this is a version that better supports the inline text elements. It also supports create and edit components
Comment on attachment 428071 [details] [diff] [review] V9 Except my name is mangled by JSON-RPC, which I guess is a separate bug, everything else is working fine. So r=LpSolit
(In reply to comment #23) > removing requestee from the title since that requires webservices we don't have > yet. Just add it to the field, for now--we can spiff it up and limit it later.
(In reply to comment #28) > There is some strange layout issue with tables (i can post a screen shot). I > will investigate it further if that is desired. Is it still a problem with your latest patch? A screenshot would be good. > The other problem is that I would have to include fields.js on the edit > components page or move it to somewhere else and including fields.js seemed > like a lot for just 1 thing. I'll start working on it and have a patch ready if > you guys would like me to add it. That's fine, you can include fields.js on the editcomponents page.
(In reply to comment #33) > Is it still a problem with your latest patch? A screenshot would be good. Not a problem anymore. The UI is fine.
> (In reply to comment #28) the strange table layout is fixed in the v9 patch. And i did include field.js as part of the v9 patch. I think we should do requestee stuff in another patch since this one is almost done and requestee appears on the attachment page and other places. I will do the requestee stuff immediately but there is a bunch of flag and attachment stuff I'd have to test/check and right now v9 is SOOOOOOO ready to be committed. But if you insist, I'll do the requestee stuff.
(In reply to comment #35) > But if you insist, I'll do the requestee stuff. IMO, a separate bug is fine.
Yeah, doing the requestee stuff somewhere else is totally fine.
bzr commit --fixes mozilla:490923 Committing to: bzr+ssh://email@example.com/bugzilla/trunk/ modified js/field.js added js/yui/bz_autocomplete_bundle.js modified skins/standard/global.css added skins/standard/yui/autocomplete.css modified template/en/default/admin/components/create.html.tmpl modified template/en/default/admin/components/edit.html.tmpl modified template/en/default/bug/field.html.tmpl modified template/en/default/bug/show-header.html.tmpl modified template/en/default/bug/create/create.html.tmpl modified template/en/default/global/header.html.tmpl modified template/en/default/global/userselect.html.tmpl modified template/en/default/list/list.html.tmpl Committed revision 7018.
Added to the release notes in bug 604256.
(In reply to comment #37) > Yeah, doing the requestee stuff somewhere else is totally fine. Was a (new) bug ever filed for doing that? I've searched and not found anything :( (If so, bug 386600 should be re-duped to the new bug, since 386600 was explicitly about the review requestee fields and this seems not to have fixed that. If a new bug wasn't filed, perhaps re-open bug 386600?)