#203 closed enhancement (fixed)
Advanced ticket query screen
| Reported by: | rocky | Owned by: | Christopher Lenz |
|---|---|---|---|
| Priority: | high | Milestone: | 0.8 |
| Component: | ticket system | Version: | 0.6 |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
As per discussion with dln on #trac (freenode), the following request came about:
Provide an advanced query screen, with all available search criteria laid out. This is more typical of mainstream bug tracker systems (see http://www.bugzilla.org) and as such would aid in the migration from another bug tracker system to Trac.
On a sidenote, its still important to keep this advanced query screen as simple as possible.
Attachments (2)
Change History (18)
comment:1 by , 20 years ago
| Milestone: | → 0.7 |
|---|
comment:4 by , 20 years ago
| Milestone: | 0.7 → 0.8 |
|---|
comment:5 by , 20 years ago
| Owner: | changed from to |
|---|---|
| Status: | reopened → assigned |
comment:6 by , 20 years ago
| Component: | general → ticket system |
|---|---|
| Priority: | normal → high |
| Summary: | request for advanced query screen → Advanced ticket query screen |
I've added a mockup of one possible approach to a generic "advanced query" page. (Note that there are some features missing from the mockup, such as sorting options, reordering fields, and colorization).
This UI is inspired by Bugzilla's "boolean charts" ( http://bugzilla.mozilla.org/queryhelp.cgi#advancedquerying ) but also from the interface email clients such as Thunderbird and Mail.app provide for setting up message filters.
The UI as shown in the screenshot needs to be heavily powered by JavaScript so that it is responsive enough for easy use (unlike the boolean charts in bugzilla, for which every many changes require a roundtrip to the server).
The advantages of this UI as I see it are:
- The user is not presented with a bloated, complex interface that displays every field/option available in the ticket system. Instead, only those fields are shown that are relevant to the query.
- The system easily scales to include custom ticket fields. It is generic while still quite intuitive to use (if it works for mail clients, why shouldn't it work for a advanced ticket query screen?)
Other opinions?
comment:7 by , 20 years ago
Comments on IRC have been:
- Provide a single 'Add' (+) button at the bottom instead of one button per row
- Separate configuration of results display from the configuration of the query constraints (the checkbox in front of every row on the screenshot was intended for including the field as column in the result table)
- It is unclear whether order of the rows is in any way relevant
comment:8 by , 20 years ago
I've added another mockup which integrates a couple of changes:
- Text search gets its own area at the top of the screen. You enter a search string and have the option of excluding any number of text fields (plus comments) from being searched for the string. Custom ticket properties of type text or textarea would get added to the array of checkboxes under the search box.
- The result filters area now only contains ticket properties of the types select, radio and checkbox. You can build queries without any such filters.
- Every row has a button for removing the filter (-), one global 'add' (+) button is placed at the bottom of the table for adding new filters.
- No controls for configuring of how the results are displayed… not sure where they should go (maybe directly on the results display page?)
comment:9 by , 20 years ago
Demo at http://www-1.informatik.fh-wiesbaden.de/~clenz001/misc/trac_query/ (client-side only).
comment:10 by , 20 years ago
| Owner: | changed from to |
|---|
Okay, I'm currently actively working on this, based on the mock-ups presented before. A draft implementation will probably go in my development branch in a day or two.
Daniel, I'm reassigning this to myself (hope you don't mind).
comment:11 by , 20 years ago
| Resolution: | → invalid |
|---|---|
| Status: | assigned → closed |
comment:12 by , 20 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
comment:13 by , 20 years ago
Approach changed: [851] adds a query results screen. The query is configurable through the query-string parameters. There's no "advanced query screen" as such for actually building the query yet.
The JavaScript-heavy approach described in previous comments didn't work out that well, main problem being behaviour of browsers when going back to the query builder page: The DOM-manipulated form would be totally messed up. I assume a simpler, more traditional approach would be the way to go for now.
comment:14 by , 20 years ago
Changeset [940] implements a rudimentary user interface for setting up queries.
comment:15 by , 20 years ago
We'll include this as a 'BETA'/experimental feature in 0.8 and polish it up at the latest for 1.0.
comment:16 by , 20 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
closing this for 0.8 now. Make new tickets for any bugs and improvements.
As per discussion with Daniel, milestone changed to 0.7.