TicketQuery Wiki Macro

The TicketQuery macro lets you display ticket information anywhere that accepts WikiFormatting. The query language used by the [[TicketQuery]] macro is described in the TracQuery page.



Wiki macro listing tickets that match certain criteria.

This macro accepts a comma-separated list of keyed parameters, in the form "key=value".

If the key is the name of a field, the value must use the syntax of a filter specifier as defined in TracQuery#QueryLanguage. Note that this is not the same as the simplified URL syntax used for query: links starting with a ? character. Commas (,) can be included in field values by escaping them with a backslash (\).

Groups of field constraints to be OR-ed together can be separated by a literal or argument.

In addition to filters, several other named parameters can be used to control how the results are presented. All of them are optional.

The format parameter determines how the list of tickets is presented:

  • list -- the default presentation is to list the ticket ID next to the summary, with each ticket on a separate line.
  • compact -- the tickets are presented as a comma-separated list of ticket IDs.
  • count -- only the count of matching tickets is displayed
  • rawcount -- only the count of matching tickets is displayed, not even with a link to the corresponding query (since 1.1.1)
  • table -- a view similar to the custom query view (but without the controls)
  • progress -- a view similar to the milestone progress bars

The max parameter can be used to limit the number of tickets shown (defaults to 0, i.e. no maximum).

The order parameter sets the field used for ordering tickets (defaults to id).

The desc parameter indicates whether the order of the tickets should be reversed (defaults to false).

The group parameter sets the field used for grouping tickets (defaults to not being set).

The groupdesc parameter indicates whether the natural display order of the groups should be reversed (defaults to false).

The verbose parameter can be set to a true value in order to get the description for the listed tickets. For table format only. deprecated in favor of the rows parameter

The rows parameter can be used to specify which field(s) should be viewed as a row, e.g. rows=description|summary

The col parameter can be used to specify which fields should be viewed as columns. For table format only.

For compatibility with Trac 0.10, if there's a last positional parameter given to the macro, it will be used to specify the format. Also, using "&" as a field separator still works (except for order) but is deprecated.


Example Result Macro
Number of Triage tickets: 172 [[TicketQuery(status=new&milestone=,count)]]
Number of new tickets: 512 [[TicketQuery(status=new,count)]]
Number of reopened tickets: 1 [[TicketQuery(status=reopened,count)]]
Number of assigned tickets: 24 [[TicketQuery(status=assigned,count)]]
Number of invalid tickets: 10 [[TicketQuery(status=closed,resolution=invalid,count)]]
Number of worksforme tickets: 20 [[TicketQuery(status=closed,resolution=worksforme,count)]]
Number of duplicate tickets: 24 [[TicketQuery(status=closed,resolution=duplicate,count)]]
Number of wontfix tickets: 18 [[TicketQuery(status=closed,resolution=wontfix,count)]]
Number of fixed tickets: 346 [[TicketQuery(status=closed,resolution=fixed,count)]]
Number of untriaged tickets (milestone unset): 175 [[TicketQuery(status!=closed,milestone=,count)]]
Total number of tickets: 955 [[TicketQuery(count)]]
Number of tickets reported or owned by current user: 14 [[TicketQuery(reporter=$USER,or,owner=$USER,count)]]
Number of tickets created this month: 0 [[TicketQuery(created=thismonth..,count)]]
Number of closed Firefox tickets: 0 [[TicketQuery(status=closed,keywords~=firefox,count)]]
Number of closed Opera tickets: 0 [[TicketQuery(status=closed,keywords~=opera,count)]]
Number of closed tickets affecting Firefox and Opera: 0 [[TicketQuery(status=closed,keywords~=firefox opera,count)]]
Number of closed tickets affecting Firefox or Opera: 0 [[TicketQuery(status=closed,keywords~=firefox|opera,count)]]
Number of tickets that affect Firefox or are closed and affect Opera: 0 [[TicketQuery(status=closed,keywords~=opera,or,keywords~=firefox,count)]]
Number of closed Firefox tickets that don't affect Opera: 0 [[TicketQuery(status=closed,keywords~=firefox -opera,count)]]
Last 3 modified tickets: #961, #454, #494 [[TicketQuery(max=3,order=modified,desc=1,compact)]]

Details of ticket #1:


Ticket Owner Reporter
#1 nobody oranfry
Summary Update Developers Guide

Format: list


This is displayed as:

Local library lock file problems
#23 output dir check
GenericList add 'removeprefix' option
Upgrade to a newer version of wv
Library cgiarg options
Basing a collection on an existing one
First characters in the log file
Public/private document authentication
New value in the attribute tables
XMLcustom plugin needed for extracting metadata from XML documents
Dragging and dropping files with weird characters into GLI
cd-rom exported collection search problem
RemoteGreenstoneServer and GLIApplet tasks
Approximate_size option for GenericList
search result sorting-ccs
Integrate the GLI code that Amin sent for working with RL languages into current GLI
Test Berry Baskets
lucene collections on exported cd-rom
Add option to installer to enable admin facility
opening non-gli collections
GLI load non-GLI collections
collectgroups in Greenstone 3
collectgroup gs3 in GLI
apache on windows


This is displayed as:

Windows 2000 EOF problem

Format: compact

[[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]

This is displayed as:

#8, #23, #37, #41, #52, #133, #166, #170, #189, #210, #322, #360, #393, #401, #407, #439, #447, #503, #518, #527, #535, #540, #553, #619

Format: count

[[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]

This is displayed as:


Format: progress


This is displayed as:

Format: table

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


This is displayed as:

Results (1 - 3 of 418)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#957 fixed Getting enriched meta to stick in GLI with special chars and encodings in subfolders and filenames ak19 ak19
#948 fixed Compiling GS3 SVN code with Visual Studio 14 nobody ak19
#947 fixed Lucene index file locking fix ak19 ak19
1 2 3 4 5 6 7 8 9 10 11

Full rows

In table format you can specify full rows using rows=<field>:


This is displayed as:

Results (1 - 3 of 418)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#957 fixed Getting enriched meta to stick in GLI with special chars and encodings in subfolders and filenames ak19 ak19

Getting enriched meta to stick in GLI with special chars and encodings in subfolders and filenames. Affected were doc.xml and metadata.xml when Gathered subfolder names and filenames contained special characters (&, + and accented chars or unicode chars beyond ascii).

Now that I have added a new bugfix related to the issue and noticed there was no ticket that brought together all the commit revisions that comprised the overall fix for this topic, I am going to try to list all the commits here., to to to to

And today's bugfix:

#948 fixed Compiling GS3 SVN code with Visual Studio 14 nobody ak19

Ticket to document what to read to get GS3 code to compile with VS 14/2015

#947 fixed Lucene index file locking fix ak19 ak19

The Lucene index file lock problem would occur because deactivating a collection on Windows didn't close all the file handles to the index dir.

The cause was opening many Index Readers (one at every query) storing them in the same member var, overwriting the reference to the previously stored open index reader. Closing the index reader happened only once: when the collection was deactivated. So lot's of zombie opened Index Readers were around on deactivation.

The initial solution was simple, to close an already instantiated index reader before using it to open any other index:

However, investigating the file locking problem exposed a greater one in Lucene: that Lucene code was allowing multiple queries but they used a single GS2LuceneQuery object per collection. So configuration for one query that's run simultaneously with others could easily use another simultaneous Query's configuration.

This was fixed here:

The solution is explained in the commit message:

"3 significant changes in 1 commit particularly impacting Lucene queries:

  1. Instead of GS2LuceneSearch having a GS2LuceneQuery object member variable for doing each and every search, each query now instantiates its own local GS2LuceneQuery object, configures it for that specific search, runs the search and then the GS2LuceneQuery object expires. This fixes a bug by preventing multiple concurrent searches getting the search configurations of other searches run at the same time.
  1. Though GS2LuceneQuery objects need to be instantiated 1 per query over a collection, we don't want to keep reopening a collection's sidx and didx index folders with IndexReader objects for every query. Since IndexReaders support concurrent access, we'd like to use one IndexReader per collection index (one for didx, one for sidx) with the IndexReaders existing for the life of a collection. This meant moving the maintaining of IndexReader objects from GS2LuceneQuery into the GS2LuceneSearch service and turning them into singletons by using a HashMap to maintain index-dir, reader pairs. GS3 Services, e.g. GS2LuceneSearch, are loaded and unloaded on collection activate and deactivate respectively. On deactivate, cleanUp() is called on services and other GS3 modules. When GS2LuceneSearch.cleanUp() is called, we now finally close the singleton IndexReader objects/resources that a collection's GS2LuceneSearch object maintains.
  1. Redid previous bugfix (then committed to GS2LuceneQuery): Point 2 again solves the filelocking problem of multiple handles to the index being opened and not all being closed on deactivate, but it's solved in a different and better/more optimal way than in the previous commit."


  • MGPP only needed the updated method signatures, and code affected code by changes to the method signatures, to be updated. (MG didn't have the same method, so it was not affected.) MG and MGPP use synchronize because they're not "multi-threaded reentrant" the way Lucene's IndexReader object is.
  • For SOLR too, only method signatures and code affected code by that change needed updating. Our Solr ext code does not open an IndexReader (or even instantiate a Searcher object with it). Our code only obtains an IndexSearcher and calls getReader on that to get access to the IndexReader. The IndexReader (and IndexSearcher) object is part of the HTTPSolrServer side of the code, the side which takes care of doGet and doPost requests. And our custom Greenstone3SearchHandler class on the HttpSolrServer side already inherits the opened IndexReader (and associated instantiated IndexSearcher). We may assume that the HttpSolrServer side takes care of optimally opening and maintaining IndexReader objects (and any way this may affect IndexSearchers), and that we can forget about this part.
1 2 3 4 5 6 7 8 9 10 11

See also: TracQuery, TracTickets, TracReports

Last modified 14 months ago Last modified on 2020-10-21T13:53:03+13:00
Note: See TracWiki for help on using the wiki.