• Introduction
• Example

Introduction

The Query Builder is RT's search engine. It lets you find tickets matching some (potentially very complex) criteria. There are loads of criteria you can specify in order to perform a search. Strategies for narrowing your searches to find exactly what you're looking for (and no more) are discussed below.

The Query Builder is the heart of reporting in RT, which is covered in the Dashboard and Reports document.

To follow along with the examples, go to issues.bestpractical.com and try the searches yourself.

Example

Let's look for tickets in the "RT" queue (RT's bugtracker for itself) that have been resolved in the last year. (These examples assume it's currently mid June, 2015). To do that, we specify the search criteria (Queue is RT, Status is resolved, and Resolved after 2014-06-15) in the upper left hand section of the Query Builder.

RT also has two meta-statuses, 'active' and 'inactive'. By selecting either of these from the status dropdown of the query builder, you will no longer need to explicitly list all of the active or inactive statuses or manually enter the queries: "Status = '__Active__'" or "Status = '__Inactive__'".

The sets of active and inactive statuses for a queue are defined by the associated lifecycle. Active tickets are those listed for the 'active' and 'initial' configurations. Inactive tickets are those defined as 'inactive'. For the default RT lifecycle, for example, the active statuses are new, open, and stalled, and the inactive statuses are resolved, rejected and deleted. See docs/customizing/lifecycles.pod for more information.

Now that I've selected some criteria, I can click either Add These Terms or Add These Terms and Search. I'll click the former:

The upper right hand side presents all the logic we've specified. This view is a nice way proofread your search: Have you captured everything you want? Are there things you'd maybe prefer to leave out for now?

It turns out I've changed my mind. I actually don't want to restrict the search to just the RT queue. I want to see all the tickets in issues.bestpractical.com (which also includes feature requests, RTIR, etc) that have been resolved within the past year. To adjust the search, click on 'AND Queue = RT' and press Delete:

Your search should now look like this:

Now, finally, to make the search go, you can either press 'Add these terms and Search' (provided there's no new content in the Query Builder), or scroll all the way down and press 'Update format and Search'. This search should turn up a full page of tickets. Here's the top portion of the list:

This is the default view of your results. However, like nearly everything in RT, it's configurable. You can select additional columns to appear in your results, eliminate columns you don't find useful, or reorder them. To start, notice that at the bottom of the query builder page there are two panes: Sorting and Display Columns.

There is more than one option for Sorting so that you can break apart tickets with the same search values into a meaningful order. For example, let's say you start off by sorting tickets in a search by their owner. Since you've only specified to sort by owner, RT doesn't order the tickets owned by the same user in a meaningful way. This is where the multiple sort criteria comes in handy. You can use a second sorting criteria to sort within the set of tickets owned by a single user. For example, you could add a sort by due date to see tickets sorted first by owner, and then tickets with the same order are ordered by due date.

The Display Columns tab allows you to add or eliminate information displayed in the results of your search. NEWLINE indicates a line break, or new row, in how the results are displayed. NBSP for adding an empty column (such as what shows up underneath id in the following screenshot).

Here is a search with NEWLINE where it is by default:

Notice that the structure of the data that's displayed is stacked: Subject on top of Requestor, Status on top of Created, etc.. Because we're displaying a lot of information (10 fields for each ticket), having the NEWLINE is important for the results more comprehensible.

Here is that same search but without the NEWLINE:

The same pieces of information are now spread across the display next to one another, which can be harder to read. So when you tell RT to display a lot of columns, it's usually worth adding a well-placed NEWLINE.

Let's say, for example, you have a custom field named 'TransportType' that takes the values, 'Car', 'Bus' or 'Train'. If you were to search for all tickets that do not have 'TransportType' set to 'Car', this would result in a list of tickets with 'TransportType' values of 'Bus', 'Train', and '(no value)'. In order to ensure that custom fields with no set value are not included in the your search results, add the following to your query:

AND CF.{TransportType} IS NOT NULL

And there are the basics of the query builder! To implement these basics to build reports, please see the Dashboard & Reports document. For definitions of piece of RT metadata, please see the Definitions of Ticket Metadata document.

← Back to index