Edgewall Software

Opened 18 years ago

Closed 18 years ago

Last modified 16 years ago

#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:


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)

query.png (45.2 KB ) - added by Christopher Lenz 18 years ago.
UI Mockup
query2.png (60.4 KB ) - added by Christopher Lenz 18 years ago.
Revised UI mockup

Download all attachments as: .zip

Change History (18)

comment:1 by rocky, 18 years ago

Milestone: 0.7

As per discussion with Daniel, milestone changed to 0.7.

comment:2 by daniel, 18 years ago

Resolution: fixed
Status: newclosed

This was fixed in [442].

comment:3 by daniel, 18 years ago

Resolution: fixed
Status: closedreopened

Oops … wrong ticket :)

comment:4 by daniel, 18 years ago

Milestone: 0.70.8

comment:5 by daniel, 18 years ago

Owner: changed from Jonas Borgström to daniel
Status: reopenedassigned

by Christopher Lenz, 18 years ago

Attachment: query.png added

UI Mockup

comment:6 by Christopher Lenz, 18 years ago

Component: generalticket system
Priority: normalhigh
Summary: request for advanced query screenAdvanced 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 Christopher Lenz, 18 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

by Christopher Lenz, 18 years ago

Attachment: query2.png added

Revised UI mockup

comment:8 by Christopher Lenz, 18 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:10 by Christopher Lenz, 18 years ago

Owner: changed from daniel to Christopher Lenz

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 anonymous, 18 years ago

Resolution: invalid
Status: assignedclosed

comment:12 by Jonas Borgström, 18 years ago

Resolution: invalid
Status: closedreopened

comment:13 by Christopher Lenz, 18 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 Christopher Lenz, 18 years ago

Changeset [940] implements a rudimentary user interface for setting up queries.

comment:15 by daniel, 18 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 daniel, 18 years ago

Resolution: fixed
Status: reopenedclosed

closing this for 0.8 now. Make new tickets for any bugs and improvements.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.