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)]]

#13740

Batch modification forms can be used incorrectly by users without TICKET_BATCH_MODIFY

#13482

6 failures in unit-test with Babel 2.10.1

#13747

IndexError raised from GitRepository.normalize_rev('FFFF') if the repository has 5000+ revisions

#13493

Make compatible with Python 3, Mercurial 6.2+ and Trac 1.5.3+

#13744

[PATCH] SpamFilter: Support pillow 10 for ImageCaptcha

[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.