Edgewall Software

Opened 14 years ago

Last modified 7 months ago

#9574 new enhancement

add filters to TicketQuery from query string arguments

Reported by: shesek Owned by:
Priority: high Milestone: next-major-releases
Component: wiki system Version: 0.13dev
Severity: normal Keywords: uservariables
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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.

Attachments (0)

Change History (6)

comment:1 by shesek, 14 years ago

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

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

comment:2 by shesek, 14 years ago

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?

in reply to:  2 ; comment:3 by Christian Boos, 14 years ago

Description: modified (diff)
Keywords: uservariables added
Milestone: next-major-0.1X
Priority: normalhigh
Version: 0.13dev

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

in reply to:  3 comment:4 by Remy Blank, 14 years ago

Replying to cboos:

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

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

comment:5 by shesek, 14 years ago

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.

comment:6 by anonymous, 13 years ago

Was this taken any further?

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.