Trac Ticket Queries

In addition to reports, Trac provides support for custom ticket queries, which can be used to display tickets that meet specified criteria.

To configure and execute a custom query, switch to the View Tickets module from the navigation bar, and select the Custom Query link.


When you first go to the query page, the default filter will display tickets relevant to you:

  • If logged in then all open tickets, it will display open tickets assigned to you.
  • If not logged in but you have specified a name or email address in the preferences, then it will display all open tickets where your email (or name if email not defined) is in the CC list.
  • If not logged in and no name/email is defined in the preferences, then all open issues are displayed.

Current filters can be removed by clicking the button to the left with the minus sign on the label. New filters are added from the pulldown lists at the bottom corners of the filters box; 'And' conditions on the left, 'Or' conditions on the right. Filters with either a text box or a pulldown menu of options can be added multiple times to perform an Or on the criteria.

You can use the fields just below the filters box to group the results based on a field, or display the full description for each ticket.

After you have edited your filters, click the Update button to refresh your results.

Clicking on one of the query results will take you to that ticket. You can navigate through the results by clicking the Next Ticket or Previous Ticket links just below the main menu bar, or click the Back to Query link to return to the query page.

You can safely edit any of the tickets and continue to navigate through the results using the Next/Previous/Back to Query links after saving your results. When you return to the query any tickets which were edited will be displayed with italicized text. If one of the tickets was edited such that it no longer matches the query criteria , the text will also be greyed. Lastly, if a new ticket matching the query criteria has been created, it will be shown in bold.

The query results can be refreshed and cleared of these status indicators by clicking the Update button again.

Saving Queries

Trac allows you to save the query as a named query accessible from the reports module. To save a query ensure that you have Updated the view and then click the Save query button displayed beneath the results. You can also save references to queries in Wiki content, as described below.

Note: one way to easily build queries like the ones below, you can build and test the queries in the Custom report module and when ready - click Save query. This will build the query string for you. All you need to do is remove the extra line breaks.

Note: you must have the REPORT_CREATE permission in order to save queries to the list of default reports. The Save query button will only appear if you are logged in as a user that has been granted this permission. If your account does not have permission to create reports, you can still use the methods below to save a query.

You may want to save some queries so that you can come back to them later. You can do this by making a link to the query from any Wiki page.

[query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]

Which is displayed as:

Active tickets against 1.0

This uses a very simple query language to specify the criteria, see Query Language.

Alternatively, you can copy the query string of a query and paste that into the Wiki link, including the leading ? character:

[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]

Which is displayed as:

Assigned tickets by owner

Customizing the table format

You can also customize the columns displayed in the table format (format=table) by using col=<field>. You can specify multiple fields and what order they are displayed in by placing pipes (|) between the columns:


This is displayed as:

Results (1 - 3 of 43)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#53 fixed wxPython error w/Analysis flip
#51 fixed win7: can't find libfftw3-3.dll flip flip
#49 duplicate HLSVDPRO passing NaN to ZLASCL flip flip
1 2 3 4 5 6 7 8 9 10 11

Full rows

In table format you can also have full rows by using rows=<field>:


This is displayed as:

Results (1 - 3 of 43)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#53 fixed wxPython error w/Analysis flip

wxPython 3.x gets upset because Analysis (in sets the locale. Traceback below. Apparently wxPython's locale behavior changed in v2.9.5.

Here's the changeset where the call to setlocale() was added:

Here's one of a number of people who had the same unpleasant surprise:

  File "c:\python27\lib\site-packages\vespa\analysis\src\", line 886, in <module>

  File "c:\python27\lib\site-packages\vespa\analysis\src\", line 880, in main
    frame = Main(db, position, size)

  File "c:\python27\lib\site-packages\vespa\analysis\src\", line 134, in __init__

  File "c:\python27\lib\site-packages\vespa\analysis\src\", line 153, in build_panes
    self.notebook_datasets  = notebook_datasets.NotebookDatasets(self, self)

  File "c:\python27\lib\site-packages\vespa\analysis\src\", line 48, in __init__

  File "C:\python27\lib\site-packages\vespa\common\wx_gravy\", line 129, in show_welcome_tab

  File "C:\python27\lib\site-packages\wx-3.0-msw\wx\", line 988, in SetPage
    return _html.HtmlWindow_SetPage(*args, **kwargs)

PyAssertionError: C++ assertion "strcmp(setlocale(LC_ALL, NULL), "C") == 0" failed at ..\..\src\common\intl.cpp(1449) in wxLocale::GetInfo(): You probably called setlocale() directly instead of using wxLocale and now there is a mismatch between C/C++ and Windows locale.
Things are going to break, please only change locale by creating wxLocale objects to avoid this!
#51 fixed win7: can't find libfftw3-3.dll flip flip

Under Win7, loading Analysis' HLSD tab fails. The error reported to Python is "[Error 126] The specified module could not be found". If one is running pythonw.exe (which is the way users run if they've installed from the standard bundle), they see the standard Vespa exception handler dialog and nothing else. When running from the command line (developer style), I get this message box in addition:

python.exe - System Error
The program can't start because libfftw3-3.dll is missing from your computer. Try reinstalling the program to fix this problem. 

That tells the real story -- Windows can't find the fftw DLL that hlsvd relies on.

It has been my experience under Windows that when DLL or EXE A relies on DLL B, Windows will find B if it is in the same directory as A. We rely on this under WinXP and it has worked fine for us there.

According to MSDN article ms682586, this is Windows' runtime search order for DLLs:

  1. The directory from which the application loaded.
  2. The system directory.
  3. The 16-bit system directory.
  4. The Windows directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable.

Based on this article, Windows shouldn't be able to find the libfftw3-3.dll under WinXP and yet it does. I can't figure out why.

In any case, that article does point to a solution, which is to change the current directory to the location of libfftw3-3.dll before loading the HLSVD DLL. This solves the problem that we see under Win7.

I attached a demo program that one can use to experiment under WinXP and Win7. It should give the same results from any directory and from 32- or 64-bit Python. You'll have to edit the code and adjust the path variable for your machine.

#49 duplicate HLSVDPRO passing NaN to ZLASCL flip flip

When using HLSVDPRO, I've seen intermittent cases of the following error:

 ** On entry to ZLASCL parameter number  4 had an illegal value

"Intermittent" isn't quite the right word to describe this problem. When it crops up, it tends to be 100% recreatable. But I've thought several times that I found the source of the problem and vanquished it, only to have it return. Since I've been unable to reliably find the magic conditions to turn it off and on, I'll describe this in general terms.

I should mention that I've seen this mostly on OS X 32 bit, but also occasionally on 64-bit Linux and never on Windows. That might be simply because I do 98% of my testing under OS X.

The problem happens in the function zsafescal() which is in zsafescal.f. It mostly consists of this:

sfmin = dlamch('s')

if (abs(alpha).ge.sfmin) then
 call zscal(n,one/alpha, x, 1)
 call zlascl('General',i,i,alpha,one,n,1,x,n,info)

In some cases, alpha (which is a parameter to zsafescal()) is NaN, hence the error "ZLASCL parameter number 4 had an illegal value".

Initially, I found that disabling optimization when compiling zsafescal.f fixed the problem. This was true regardless of whether I disabled optimization just this one file or the whole project. This led me to suspect that zsafescal() was doing something unusual which was tripping up the compiler's optimizer.

zsafescal() used the Fortran keyword "save" (which creates something similar to a C static variable) so I eliminated the use of that. This made the problem disappear even when optimization was turned on, so I felt sure I'd solved the problem.

HLSVDPRO worked for a while, then the problem came back. Even disabling optimization didn't help.

I was able to see that the NaN passed to zsafescal() was really the problem, so I investigated the callers. There are 5 calls to zsafescal() in zlanbprow.f. I tried to debug this problem by adding print statements just before each call to zsafescal() so I could see which one was passing NaN. Curious thing is, adding the print statements makes the problem disappear. In fact, this is the only way I've found I can consistently squash this problem. At first I printed the value of alpha but I found that even printing "" made the problem disappear.

Based on this, my guess is that there's something on the stack that should not be on the stack when zsafescal() is called. When I add a print statement, it's the print that receives the broken stack and not zsafescal(). For whatever reason, print isn't troubled by this whereas zsafescal() is.

I have further evidence to support this theory. Printing to the console is OK when testing but not OK for a release-worthy version of Analysis. So I replaced the print statements with a call to a function I wrote called donothing(). That function writes "" to /dev/null instead of to stdout. Calling donothing() just before each call to zsafescal() also makes the problem disappear. In fact, it even does so if I comment out the code that writes "" to /dev/null.

I have researched compiler flags and double checked that function declarations match (i.e. not passing single precision where double is expected) and haven't found any clues. I'm frustrated and a little embarrassed to admit that I haven't been able to nail this problem down.

For now, I'm going to leave donothing() in the code as a patch that I hope is temporary but realistically realize might be long term.

1 2 3 4 5 6 7 8 9 10 11

Query Language

query: TracLinks and the [[TicketQuery]] macro both use a mini “query language” for specifying query filters. Filters are separated by ampersands (&). Each filter consists of the ticket field name, an operator and one or more values. More than one value are separated by a pipe (|), meaning that the filter matches any of the values. To include a literal & or | in a value, escape the character with a backslash (\).

The available operators are:

= the field content exactly matches one of the values
~= the field content contains one or more of the values
^= the field content starts with one of the values
$= the field content ends with one of the values

All of these operators can also be negated:

!= the field content matches none of the values
!~= the field content does not contain any of the values
!^= the field content does not start with any of the values
!$= the field content does not end with any of the values

The date fields created and modified can be constrained by using the = operator and specifying a value containing two dates separated by two dots (..). Either end of the date range can be left empty, meaning that the corresponding end of the range is open. The date parser understands a few natural date specifications like "3 weeks ago", "last month" and "now", as well as Bugzilla-style date specifications like "1d", "2w", "3m" or "4y" for 1 day, 2 weeks, 3 months and 4 years, respectively. Spaces in date specifications can be omitted to avoid having to quote the query string.

created=2007-01-01..2008-01-01 query tickets created in 2007
created=lastmonth..thismonth query tickets created during the previous month
modified=1weekago.. query tickets that have been modified in the last week
modified=..30daysago query tickets that have been inactive for the last 30 days

See also: TracTickets, TracReports, TracGuide, TicketQuery

Last modified 2 years ago Last modified on Sep 17, 2018, 4:52:20 PM