wiki:TracQuery

Trac Ticket Queries

In addition to reports, Trac provides support for custom ticket queries, used to display lists of tickets meeting a specified set of criteria.

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

Filters

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 and no name/email 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 of 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.

Once you've 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

Using the [[TicketQuery]] Macro

The TicketQuery macro lets you display lists of tickets matching certain criteria anywhere you can use WikiFormatting.

Example:

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

This is displayed as:

No results

Just like the query: wiki links, the parameter of this macro expects a query string formatted according to the rules of the simple ticket query language. This also allows displaying the link and description of a single ticket:

[[TicketQuery(id=123)]]

This is displayed as:

#123
CBC.exe produces an "optimal" IP solution that violates a BigM constraint - a scaling problem?

A more compact representation without the ticket summaries is also available:

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

This is displayed as:

No results

Finally, if you wish to receive only the number of defects that match the query, use the count parameter.

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

This is displayed as:

0

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 by placing pipes (|) between the columns like below:

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

This is displayed as:

Results (1 - 3 of 186)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#187 migrated CBC crashes on windows machines tkr djamel
#186 migrated Feasible problem reported as infeasible tkr dindy
#185 migrated Preprocessing Error with CBC in pyomo tkr adimodi610
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> like below:

[[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 186)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#187 migrated CBC crashes on windows machines tkr djamel
Description

Dear all, I am trying to solve the attached lp model with CBC on a 64 bit windows machine with Visual Studio 2013. The problem is that CBC crashes before finishing Branch&Cut. I tried with different CBC versions: CBC 2.7 (stable), CBC 2.9 (stable), trunk, and CBC 2.9.8. The same error occurs in the same place. I converted the lp file to an mps file and it crashed again. Attached are the .lp (compressed) and the .cpp files. Note that on Ubuntu it works fine.

Following is an instance of the log output:

Welcome to the CBC MILP Solver Version: 2.7 Build Date: Dec 10 2018

command line - Test -solve -quit (default strategy 1) Continuous objective value is 80.7531 - 241.00 seconds Cgl0004I processed model has 306368 rows, 306789 columns (306789 integer) and 847187 elements Objective coefficients multiple of 1 Cutoff increment increased from 1e-005 to 0.999

Thank you for your support!

kind regards,

Djamel

#186 migrated Feasible problem reported as infeasible tkr dindy
Description

Hello,

the attached problem is reported as infeasible by CBC 2.9.9, even though it is feasible. Command line used is simply:

cbc -import inf.lp -solve -quit

If I set the ratiogap to an high value, say 0.5, a (suboptimal) feasible solution is found.

CBC has been compiled with mingw32 but I tested also with the supplied MSVC precompiled binaries to be sure it isn't just some compilation issue.

Hope it helps, and thanks for this excellent software.

Bye,

Denis Sbragion

#185 migrated Preprocessing Error with CBC in pyomo tkr adimodi610
Description

Hi

I am solving a integer programming problem with CBC using pyomo in python.

When i am not specifying Preprocessing= "off" in model. CBC is giving following output.

Cbc0004I Integer solution of -18673.699 found after 106285 iterations and 5977 nodes (26.18 seconds)
Cbc0010I After 6000 nodes, 172 on tree, -18673.699 best solution, best possible -19341.306 (26.40 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 98 rows 123 columns
Cbc0010I After 7000 nodes, 606 on tree, -18673.699 best solution, best possible -19341.306 (30.37 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 97 rows 122 columns
Cbc0038I Full problem 487 rows 665 columns, reduced to 97 rows 122 columns
Cbc0010I After 8000 nodes, 1036 on tree, -18673.699 best solution, best possible -19341.306 (33.06 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 99 rows 124 columns
Cbc0012I Integer solution of -19005.863 found by rounding after 135072 iterations and 8417 nodes (34.26 seconds)
Cbc0012I Integer solution of -19165.821 found by rounding after 135100 iterations and 8424 nodes (34.28 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 66 rows 90 columns
Cbc0010I After 9000 nodes, 437 on tree, -19165.821 best solution, best possible -19341.306 (37.47 seconds)
Cbc0010I After 10000 nodes, 501 on tree, -19165.821 best solution, best possible -19341.306 (40.19 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 61 rows 83 columns
Cbc0010I After 11000 nodes, 522 on tree, -19165.821 best solution, best possible -19341.306 (42.42 seconds)
Cbc0010I After 12000 nodes, 878 on tree, -19165.821 best solution, best possible -19248.291 (56.64 seconds)
Cbc0010I After 13000 nodes, 1118 on tree, -19165.821 best solution, best possible -19232.913 (66.89 seconds)
Cbc0004I Integer solution of -19176.303 found after 304826 iterations and 13286 nodes (67.40 seconds)
Cbc0004I Integer solution of -19201.71 found after 309361 iterations and 13492 nodes (68.12 seconds)
Cbc0010I After 14000 nodes, 571 on tree, -19201.71 best solution, best possible -19232.913 (69.75 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 99 rows 136 columns
Cbc0010I After 15000 nodes, 577 on tree, -19201.71 best solution, best possible -19219.817 (79.08 seconds)
Cbc0011I Exiting as integer gap of 18.106987 less than 1e-10 or 0.1%
Cbc0001I Search completed - best objective -19201.70987434507, took 378930 iterations and 15001 nodes (79.10 seconds)
Cbc0032I Strong branching done 19396 times (255204 iterations), fathomed 333 nodes and fixed 2694 variables
Cbc0035I Maximum depth 151, 35742 variables fixed on reduced cost
0  Obj -21105.956 Primal inf 4822.701 (250) Dual inf 9.2984993e+13 (172)
End of values pass after 86 iterations
86  Obj -19926.913 Primal inf 455.19681 (89) Dual inf 5.1983959e+13 (105)
Perturbing problem by 0.001 % of 108.83248 - largest nonzero change 0.00080540261 (% 0.00085681129) - largest zero change 1.9933183e-05
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
Primal infeasible - objective value -19201.71
Cuts at root node changed objective from -22813.4 to -19341.3
Probing was tried 16542 times and created 78915 cuts of which 109 were active after adding rounds of cuts (4.173 seconds)
Gomory was tried 15528 times and created 31132 cuts of which 0 were active after adding rounds of cuts (5.924 seconds)
Knapsack was tried 15529 times and created 16043 cuts of which 0 were active after adding rounds of cuts (9.498 seconds)
Clique was tried 15 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.001 seconds)
MixedIntegerRounding2 was tried 15529 times and created 19002 cuts of which 0 were active after adding rounds of cuts (4.872 seconds)
FlowCover was tried 15 times and created 39 cuts of which 0 were active after adding rounds of cuts (0.008 seconds)
TwoMirCuts was tried 15528 times and created 6703 cuts of which 0 were active after adding rounds of cuts (2.403 seconds)
ImplicationCuts was tried 501 times and created 6044 cuts of which 0 were active after adding rounds of cuts (0.034 seconds)
Cgl0014I Postprocessing changed objective from -19201.71 to 0 - possible tolerance issue - try without preprocessing

Result - Optimal solution found (within gap tolerance)

Objective value:                -19201.70987435
Lower bound:                    -19219.817
Gap:                            0.00
Enumerated nodes:               15001
Total iterations:               378930
Time (CPU seconds):             78.91
Time (Wallclock seconds):       79.12

Total time (CPU seconds):       78.97   (Wallclock seconds):       79.18

But when i am specifying, Preprocessing = "off" in model, getting following output.

Cbc0010I After 1400 nodes, 501 on tree, -17956.092 best solution, best possible -19454.06 (57.00 seconds)
Cbc0038I Full problem 10441 rows 10504 columns, reduced to 49 rows 72 columns
Cbc0012I Integer solution of -18008.126 found by RINS after 42458 iterations and 1500 nodes (62.35 seconds)
Cbc0010I After 1500 nodes, 544 on tree, -18008.126 best solution, best possible -19454.06 (62.35 seconds)
Cbc0010I After 1600 nodes, 595 on tree, -18008.126 best solution, best possible -19454.06 (67.16 seconds)
Cbc0010I After 1700 nodes, 645 on tree, -18008.126 best solution, best possible -19454.06 (71.17 seconds)
Cbc0038I Full problem 10441 rows 10504 columns, reduced to 44 rows 71 columns
Cbc0012I Integer solution of -18277.113 found by RINS after 52959 iterations and 1800 nodes (75.27 seconds)
Cbc0010I After 1800 nodes, 634 on tree, -18277.113 best solution, best possible -19454.06 (75.27 seconds)
Cbc0010I After 1900 nodes, 679 on tree, -18277.113 best solution, best possible -19454.06 (80.47 seconds)
Cbc0010I After 2000 nodes, 727 on tree, -18277.113 best solution, best possible -19454.06 (84.79 seconds)
Cbc0010I After 2100 nodes, 777 on tree, -18277.113 best solution, best possible -19454.06 (89.12 seconds)
Cbc0010I After 2200 nodes, 820 on tree, -18277.113 best solution, best possible -19454.06 (93.46 seconds)
Cbc0010I After 2300 nodes, 863 on tree, -18277.113 best solution, best possible -19454.06 (97.97 seconds)
Cbc0038I Full problem 10441 rows 10504 columns, reduced to 42 rows 63 columns
Cbc0010I After 2400 nodes, 908 on tree, -18277.113 best solution, best possible -19454.06 (102.29 seconds)
Cbc0010I After 2500 nodes, 957 on tree, -18277.113 best solution, best possible -19454.06 (106.65 seconds)
Cbc0010I After 2600 nodes, 1005 on tree, -18277.113 best solution, best possible -19454.06 (111.13 seconds)
Cbc0010I After 2700 nodes, 1051 on tree, -18277.113 best solution, best possible -19454.06 (115.26 seconds)
Cbc0010I After 2800 nodes, 1099 on tree, -18277.113 best solution, best possible -19454.06 (119.16 seconds)
Cbc0020I Exiting on maximum time
Cbc0005I Partial search - best objective -18277.113 (best possible -19454.06), took 97910 iterations and 2822 nodes (120.03 seconds)
Cbc0032I Strong branching done 11466 times (68270 iterations), fathomed 17 nodes and fixed 157 variables
Cbc0035I Maximum depth 147, 2435 variables fixed on reduced cost
Cuts at root node changed objective from -25143.8 to -19454.1
Probing was tried 5616 times and created 41164 cuts of which 31 were active after adding rounds of cuts (6.332 seconds)
Gomory was tried 5611 times and created 12474 cuts of which 0 were active after adding rounds of cuts (14.109 seconds)
Knapsack was tried 5611 times and created 2807 cuts of which 0 were active after adding rounds of cuts (36.735 seconds)
Clique was tried 20 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.003 seconds)
MixedIntegerRounding2 was tried 5611 times and created 9514 cuts of which 0 were active after adding rounds of cuts (8.361 seconds)
FlowCover was tried 5611 times and created 988 cuts of which 0 were active after adding rounds of cuts (1.096 seconds)
TwoMirCuts was tried 5611 times and created 1985 cuts of which 0 were active after adding rounds of cuts (10.246 seconds)
ImplicationCuts was tried 34 times and created 198 cuts of which 0 were active after adding rounds of cuts (0.003 seconds)

Result - Stopped on time limit

Objective value:                -18277.11318678
Lower bound:                    -19454.060
Gap:                            0.06
Enumerated nodes:               2822
Total iterations:               97910
Time (CPU seconds):             119.41
Time (Wallclock seconds):       120.04

Total time (CPU seconds):       119.47   (Wallclock seconds):       120.10


The main problem is why do we need to specify preprocessing = "off" to get solution?

and when preprocessing is on, why it is converting optimal solution (objective) to 0.

Cgl0014I Postprocessing changed objective from -19201.71 to 0 - possible tolerance issue - try without preprocessing

I am also attaching LP problem file for your reference.

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. Basically, the filters are separated by ampersands (&). Each filter then 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 left out 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

Last modified 6 years ago Last modified on Aug 20, 2013 9:17:14 PM