wiki:TicketQuery

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.

Usage

[[TicketQuery]]

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.

Examples

Example Result Macro
Number of Triage tickets: 31 [[TicketQuery(status=new&milestone=,count)]]
Number of new tickets: 195 [[TicketQuery(status=new,count)]]
Number of reopened tickets: 9 [[TicketQuery(status=reopened,count)]]
Number of assigned tickets: 146 [[TicketQuery(status=assigned,count)]]
Number of invalid tickets: 65 [[TicketQuery(status=closed,resolution=invalid,count)]]
Number of worksforme tickets: 69 [[TicketQuery(status=closed,resolution=worksforme,count)]]
Number of duplicate tickets: 133 [[TicketQuery(status=closed,resolution=duplicate,count)]]
Number of wontfix tickets: 142 [[TicketQuery(status=closed,resolution=wontfix,count)]]
Number of fixed tickets: 1145 [[TicketQuery(status=closed,resolution=fixed,count)]]
Number of untriaged tickets (milestone unset): 118 [[TicketQuery(status!=closed,milestone=,count)]]
Total number of tickets: 2342 [[TicketQuery(count)]]
Number of tickets reported or owned by current user: 44 [[TicketQuery(reporter=$USER,or,owner=$USER,count)]]
Number of tickets created this month: 10 [[TicketQuery(created=thismonth..,count)]]
Number of closed Firefox tickets: 1 [[TicketQuery(status=closed,keywords~=firefox,count)]]
Number of closed Opera tickets: 1 [[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: 2 [[TicketQuery(status=closed,keywords~=firefox|opera,count)]]
Number of tickets that affect Firefox or are closed and affect Opera: 2 [[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: #2591, #2506, #2427 [[TicketQuery(max=3,order=modified,desc=1,compact)]]

Details of ticket #1:

[[TicketQuery(id=1,col=id|owner|reporter,rows=summary,table)]]

Ticket Owner Reporter
#1 zzz
Summary News Fetcher Fix

Format: list

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

This is displayed as:

No results

[[TicketQuery(id=123)]]

This is displayed as:

No results

Format: compact

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

This is displayed as:

No results

Format: count

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

This is displayed as:

0

Format: progress

[[TicketQuery(milestone=0.12.8&group=type,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:

[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]

This is displayed as:

Results (1 - 3 of 1801)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#2584 fixed Reduce the fixed 250ms ack delay Zlatin Balevsky
#2583 duplicate Orchid doesn't timeout unresolvable requests zzz Reportage
#2582 fixed Higher priority message in SSU causes stall zzz Zlatin Balevsky
1 2 3 4 5 6 7 8 9 10 11

Full rows

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

[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]

This is displayed as:

Results (1 - 3 of 1801)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#2584 fixed Reduce the fixed 250ms ack delay Zlatin Balevsky
Description

See https://trac.i2p2.de/ticket/1939#comment:14 for background on how this was discovered.

I performed 5 test runs in the testnet with each value below with a 25MB file. It is interesting to see how up to a point reducing the value increases the speed.

ack delay(ms) | speeds (kb/s) =================== 300 | 150, 125, 119, 156, 166 250 | 169, 147, 142, 168, 179 200 | 192, 198, 214, 156, 198 150 | 179, 296, 332, 204, 212 100 | 166, 212, 222, 274, 196 50 | 88, 123, 76, 86, 250

I ran a t-test and there is less than 1.3% chance the difference between the 250ms and 150ms samples occurred by chance.

https://www.statisticshowto.datasciencecentral.com/probability-and-statistics/t-test/ https://help.libreoffice.org/Calc/Statistical_Functions_Part_Five#TTEST

It's hard to say to what extent this reflects the conditions in the live network, but I think it's worth considering a reduction in the ack delay.

#2583 duplicate Orchid doesn't timeout unresolvable requests zzz Reportage
Description

If a request is made for an unresolvable domain, Orchid will repeatedly attempt to connect to the domain until restarted. A request to http://foo.org, for example, will fail initially, prompting a site not found error in the browser, and then Orchid will over time repeatedly attempt to connect, indicated in the UI.

If the site is not resolvable, Orchid should register the fact and abort all connection attempts until the site is manually re-requested.

#2582 fixed Higher priority message in SSU causes stall zzz Zlatin Balevsky
Description

Consider the following code:

         // Peek at head of _outboundQueue and see if we can send it.
            // If so, pull it off, put it in _outbundMessages, test
            // again for bandwidth if necessary, and return it.
            OutboundMessageState state;
            while ((state = _outboundQueue.peek()) != null &&
                   ShouldSend.YES == locked_shouldSend(state)) {
                // we could get a different state, or null, when we poll,
                // due to AQM drops, so we test again if necessary
                OutboundMessageState dequeuedState = _outboundQueue.poll();
                if (dequeuedState != null) {
                    _outboundMessages.add(dequeuedState);
                    if (dequeuedState == state || ShouldSend.YES == locked_shouldSend(state)) {
                        if (_log.shouldLog(Log.DEBUG))
                            _log.debug("Allocate sending (NEW) to " + _remotePeer + ": " + dequeuedState.getMessageId());
                        if (rv == null)
                            rv = new ArrayList<OutboundMessageState>(MAX_ALLOCATE_SEND);
                        rv.add(state);
                        if (rv.size() >= MAX_ALLOCATE_SEND)
                            return rv;
                    }
                }
            }

And note that locked_shouldSend() updates the nextSendTime to be rto from now. So if a higher priority message is inserted in the queue between the peek() and the poll(), the check for equality will fail and the second check will ALWAYS fail (because the first thing locked_shouldSend checks is the nextSendTime).

As a result, the higher priority message will enter the _outboundMessages but the previous head of the queue will not be sent until one rto from now, causing a stall.

The following logs illustrate the effects:

2019/08/01 19:10:49.853 DEBUG [acket pusher] router.transport.udp.PeerState: Nothing to send to [Hash: 2eCs7jCRx6XP7f0tEho-Sv8-sl~6FrmnxkVmA6HpdNs=], with 0 / 5 remaining
1 2 3 4 5 6 7 8 9 10 11


See also: TracQuery, TracTickets, TracReports

Last modified 2 months ago Last modified on Jun 12, 2019 9:17:43 PM