add filters to TicketQuery from query string arguments

[shesek]

I'm using wiki pages and the TicketQuery macro to create ticket summary/overview pages, as I find them much more flexible than reports as I can have multiple 'views' on the same page (for example, have 'Assigned to you', 'Awaiting assignment', 'In progress', etc - each shows top 10, has different filters and ordered by different columns, all in the same page. Creating a page like that isn't possible with reports).

So - what I'm trying to do is create a per-project ('project' being a custom field I added) and per-components ticket overview using the Wiki. Instead of copying the wiki page for every project/component I have, I want to use something like wiki/TicketSummary?project=foobar and than read the query-string argument (project) to be used inside the TicketQuery macro and [query:].

I was trying to do it using IWikiSyntaxProvider and get_wiki_syntax (​http://pastie.org/private/evw1r9jkhcmq3m6jjgrojw), by replacing ${foobar} with req.args['foobar'], which works - but not inside other macros.

I think the best way is adding this functionality to core, by parsing custom arguments inside the TicketQuery macro and [source:] link, in a similar way to how $USER is replaced with the currently logged in user - but replacing them with query-string arguments instead.

This will give users better control and flexibility in creating their own custom ticket overviews, which can replace the reports in some cases if those pages could be dynamic and show different content based on arguments.

[shesek]

Sorry, in the 4th paragraph I meant [query:] and not [source:]:

… inside the TicketQuery macro and [query:] link …

[shesek]

It might also be worth reading #9617 and comment:4:ticket:9617 to understand the use-cases for that. Also, any specific reason I got no reply so far?

[Christian Boos]

We could indeed try to support user variables throughout the wiki.

Implementation notes: we could reuse the code from ReportModule.get_var_args and pass those parameters as "variables" through the mimeview.Context (similar to mechanism than rendering hints).

Replying to shesek:

Also, any specific reason I got no reply so far?

Bad timing, never create tickets while I'm on holidays ;-)

[Remy Blank]

Replying to cboos:

Bad timing, never create tickets while I'm on holidays ;-)

… and I'm sick at the same time :)

[shesek]

Awesome. Thanks, you rock! :-) That'll allow me to create some really useful wiki pages.

Its not a must at all, but what about support for optional arguments? What I'm currently using are wiki pages that looks ​like that, would be nice if we could use some syntax so the same wiki page could support filtering by some field (when passing an query string argument) and display all tickets (when no arguments are passed) without having to create a separate wiki page.

[anonymous]

Was this taken any further?