TicketQueryMacro should be able to filter fields by date range

[erne.castro@…]

The idea come to me while thinking it would be nice to have queries like:

• Tickets close in the last week.
• Tickets reopened in the last week.
• Etc.

I think this could be implemented if it would be possible to specify a field value and a give time frame when it was set.

So, to get the "close in last week" one could query something like:

[[TicketQuery(format=table,order=priority,group=component,status=closed@-7d&component^=MyLittleComponent&version=1.23)]]

Where @-7d would mean that the status has to be set to closed in the past 7 days.

I do not know if this is a good idea, neither if the format is good… but I think it would be nice to have this built-in rather as a plugin.

[Ryan J Ollos <ryano@…>]

I've changed the ticket description so that this is not easily confused with a similar and common feature request, to be implemented in Reports (which can be done by writing a SQL query).

I'd find a feature such as this useful since I have Recently Completed Tickets listed on WikiStart of my Trac site, but the resulting list is not actually a list of the most recently completed tickets, but rather the most recently updated tickets that have status closed. This is the best I've been able to come up with given the existing TicketQuery Macro's functionality

[[TicketQuery(format=list, max=5, status=closed, resolution=fixed, desc=True, order=changetime)]]

#13804

convert_db fails if both spamfilter and tags plugin are enabled

#13784

wikiColumn in wiki.js makes forcibly the background of elements white

#13802

Focused item of autocomplete menu in diff view should have background color

#13803

_libpq_pathname in postgres_backend.py should be a str instance

#13794

encoding error in diff

[anonymous]

Another idea that may help solve this issue (and is usefull by itself) is to be able to use the TicketQuery starting from a given report.

That is, the same macro as today, but to be able to specify on which report to perform the query.

This way, one could write a "Closed in past N days report" and then use this report (view) in a TicketQuery and further filter it by component or owner or whatever.

[Ryan J Ollos <ryano@…>]

Replying to anonymous:

Another idea that may help solve this issue (and is usefull by itself) is to be able to use the TicketQuery starting from a given report.

That is, the same macro as today, but to be able to specify on which report to perform the query.

This way, one could write a "Closed in past N days report" and then use this report (view) in a TicketQuery and further filter it by component or owner or whatever.

Even if that modification is not made to the TicketQuery macro, I could see how that would make a useful macro available through t-h.o … ReportQueryMacro?

[Christian Boos]

Well, have you read the TracQuery#QueryLanguage section? Filtering by date does work, at least for the created and modified fields.

I don't know about the custom date fields though (#1942), maybe Remy could comment on that (or I could test the branch, at last ;-) ).

[Steffen Hoffmann]

Replying to cboos:

Well, have you read the TracQuery#QueryLanguage section? Filtering by date does work, at least for the created and modified fields.

I don't know about the custom date fields though (#1942), maybe Remy could comment on that (or I could test the branch, at last ;-) ).

It just works, tested this today. However unlike the created and modified fields we should prepare for

• optionally including tickets without time stamp specified independed of time range selection (in current TracQuery implementation it depends on the start value for the time range: if set, query does excludes tickets with empty custom time field, and includes them, if not set)
• constraints in the future, like 'nextweek' or '+7d', since it is perfectly valid i.e. to search all tickets with due_date of this week

As Remy invited me to go on with his much cleaner rework of my initial implementation, I'll do so now and - among other things - provide patches to provide the aforementioned functionality.

[Steffen Hoffmann]

See comment:54:ticket:1942 for a suggested implementation of TracQuery future constraints.