near the end of http://drupal.org/node/64648, dries suggested:
PS: can we wrap the search box in a fieldset so they look consistent with the 'Project information' fieldset, and the 'Issue information' fieldset on the 'new issue comment' page? :)
which he later clarified as:
The quick search bar on top of issue listings doesn't use a fieldset (example). I suggested (or tried suggesting ;)) that we make it use a fieldset as well (like the other "bars" in the project module).
basically, now that the create a new issue (or followup) form has the fieldsets that hold all the form elements horizontally (http://drupal.org/node/62129), we could attempt to do a similar thing on the issue query page, too, instead of the theme_ hook we're using now to stuff the form elements into a table (which used to be the state-of-the-art for this kind of thing).
while we're at it, we should probably use 2 bars of select elements (just like the other form), so you can query for whatever you want (what's there now, plus component, version, and possibly assigned). unfortunately, that gets tricky since the values to populate into the select box for component and version depend on what project is selected, so either we have to do some kind of active-select AJAX mojo to automatically alter the options whenever the project value is changed, or come up with a different plan...
if it's not going to have a good solution for adding version and component selectors, i'm not sure this UI change is worth the effort at the moment. just wanted to file a new issue to keep this work separate from #64648 (which was more limited in scope, and is now resolved).
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | firefox.pdf | 15.41 KB | dries |
Comments
Comment #1
dries commentedI looked at Worpress' issue tracker (they use Trac) and they don't support paging. They just list all bugs on a single page (entry page). Makes it easy to search for a bug; just hit Cmd-F / Ctrl-F. ;)
Comment #2
dwwhehe. no thanks. ;) obviously, we still need the ability to filter so that you only see issues that match what you're looking for. e.g. i've got a browser open with tabs for "needs review", "RTBC", "needs work" and "active". each one just has the appropriate URL in it to query all my issues in that state (e.g. http://drupal.org/project/issues/user?states=8). so, i can easily see where things i've been working on are at, what needs some loving, what needs me to go pester folks to review, etc. ;) trying to do that via everything on a giant page i had to scroll through would be a nightmare...
Comment #3
dries commentedThis is what my Firebox bookmark toolbar looks like. The quick issue search toolbar really doesn't cut it for me. Without these bookmarks, I'd be pretty lost (or wasting a lot of time navigating around).
Comment #4
killes@www.drop.org commentedHow come this is so similar to mine? :p
Comment #5
dwwFYI, both http://drupal.org/node/29848 and http://drupal.org/node/55117 are duplicates with part of this. but, i ended up marking both of those as the dups, even though #29848 is the oldest, since this issue is now talking about more far-reaching changes to the UI, not just adding component to the search bar.
Comment #6
dwwhttp://drupal.org/node/38122 is also now marked as duplicate with this.
Comment #7
dwwbump: at http://drupal.org/node/138057 (now marked duplicate), merlinofchaos also suggests including a box for keyword searching. i'm moving that suggestion into here, since i'm worried about making the default search bar too busy/cluttered if we keep cramming stuff into it. i think it'll all work (especially if we make it 2 bars, not just 1), but i'd like to have the big picture in mind when working on this.
Comment #8
dwwComment #9
aclight commentedLets postpone this until #76725: Refactor project issue module to use Views gets finished. Views2 may be so fancy that we can get a lot closer to what we want without writing much additional code.
Comment #10
dwwI think the new views-based issue queues solve all these problems.