Fix "Project" exposed filters on issue queue views

Ok, this looks like the right place to vote for a select box on the http://d6.drupal.org/project/user page. It would make it much clearing what the filters on this page do.

We discussed this at length in #drupal tonight. A summary:

In general, it makes a lot more sense to be consistent whenever possible. A multivalued autocomplete gives us the best flexibility because it's the most complex case, which means you can re-use it everywhere, getting a nice little feature enhancement at places like project/issues to bring up both the Project issue tracking and Project issues in one view, for instance, without having to monkey around with advanced search.

However, on both project/user and project/issues/user, it makes a lot of sense to filter the available list of autocompletable stuff by what projects you own, and what issues you've responded to. Derek is pretty confident he can build such intelligence into the autocomplete widget.

But project/user is a special case where there will only ever be a few options here. In classic UI design terms, a select widget makes a lot more sense. It kinda sucks to special-case this page (both because it's more code to maintain and also because it's confusing to users), but this is less a user-facing page and more a contributor-facing page, and so optimizing the user experience for them is important.

So, in summary:
Multiselect autocomplete widgets everywhere but project/user.
The autocomplete widget on project/issues/user will be filtered to only relevant projects.
project/user uses a select widget instead of an autocomplete one (also filtered to only relevant projects).

Forgive me for not looking into the code itself to answer my own question, but my feeling is that for many of the non d.o sites that use project* (and specifically project issue), having autocomplete fields in the places webchick mentioned above will be more confusing than a select box. Given that most sites probably don't have nearly the number of projects as we have on d.o, there is less inefficiency in terms of bandwidth and page loading time to have a select box, and just less need from the users perspective since there will be far fewer projects to choose from.

So my question is whether the discussion above, primarily webchick's comment in #3, applies just to the possibly customized views for project issue stuff used on d.o, or the default views that will ship with project_issue. If the later, will it be trivial for a site builder/administrator to use select boxes instead, or would that require hacking the code or writing additional filter handlers?

I realize our prime focus right now is getting project* working for d.o, and that's fine, but I want to make sure that we at least think about how non d.o sites might use project* and don't build anything that might be seen as a major regression for other sites.

Also, I liked the idea of the hybrid select box/autocomplete that was proposed in #201435-16: Huge list of projects hard to use, consumes excessive d.o. bandwidth, can hang browser but it looks like the issue was fixed by just doing an autocomplete instead. I've noticed that Gmail just got a new interface that includes a hybrid autocomplete/select box that is pretty spiffy (see http://gmailblog.blogspot.com/2009/02/new-ways-to-label-with-move-to-and... for blog post and screen shots). Such a widget wouldn't solve our problem in most places on sites with lots of projects like d.o, because we'd still have to load in all of the projects. However for smaller sites it would really be the best of both worlds--users could autocomplete or select as they desired. It would also be a nice solution at project/user (with proposed filtering for relevant projects) and probably project/issues/user.

I can't offer to write such a widget as that would require learning javascript first, but I wanted to point it out.

Sounds like a great plan to me.

project/user looks good. I can't wait to get to use this for real.