Filter extensions

[NickW]

With ClearQuest queries (similar to JIRA's Filters) it is possible to define a basic filter, but to elect a particular field as being dynamic. In so doing the user is then shown a dialog in to which they can enter a value; or slect from a predfined list of values when the query is run. Simply entering this and pressing OK then runs the query.

eg. Show all closed bugs after a user defined date

The point is the user runs the query, a dialog is displayed into which they enter data and the results are displayed. The user doesnt have to go and edit the existing filter to change its behaviour.

Is there a similar feature available in JIRA?

[Renjith Pillai]

Something similar to what Jozef said. We used to use Confluence with run macro and the user fills in the arguments and then those values were taken directly into the jql argument for the isssue search in JIRA and the results shown.

[Jozef Kotlár]

There is no such functionality out of the box, as Nic written, anyway there are use cases where it would be benefitial. We should distinguish between filtering and exact searching in predefined set of issues.

In our customized JIRA installation are users routinely searching for orders by their identifier, they don't want the fiddle with filter to do the search. We have provided them with search gadget allowing to AND predefined filter with exact search for given customfield.

At the very beginning it start as generic text gadget with simple form and javascript placed on dashboard, something like this:

<form action="/jira/secure/IssueNavigator.jspa" target="_parent">
<script type="text/javascript">
function mySearch(orderNr) {
    var result = 'type = \"Order\" ';
    
    if(orderNr) return result + 'AND OrderNr = \"' + orderNr + '\"';
    return result; 
}
</script>

<input type="hidden" name="jqlQuery" />
<input type="hidden" name="reset" value="true" />

<table>
	<tr> <td>OrderNr:</td> <td><input type="text" name="OrderNr" /></td><td><input type="submit" value="Go" onclick="this.form.elements['jqlQuery'].value=mySearch(this.form.elements['OrderNr'].value)" /></td></tr>
</table>
</form>

[Nic Brough -Adaptavist-]

No, it doesn't.

Personally, although I can see the logic behind it, I find it's actually a bad idea.

I save and share the more obvious "base" filters for people and then invest a little time in showing them how to take a base filter and extend or modify a copy to suit themselves. Teaching people to filter seems to be far more useful than getting them to do things by rote, it helps them to understand and question their data.

[Nic Brough -Adaptavist-]

Oh, and the simple filter definition in 5.2 is far more friendly for defining filters.

[NickW]

At one level I agree. But sometimes it makes sense for people to use standard filters e.g. when looking at metrics etc.

[Nic Brough -Adaptavist-]

That's why we save and share standard filters. If you look at the dashboard gadgets (we set up shared common dashboards too), you can do things like "show this filter and push it through a report where the user can choose which field to group the results on" (filter statistics gadget). Far more useful than a predefined filter with one variable they enter - again it encourages them to understand their own data.

[Jozef Kotlár]

I agree with friendliness of filtering GUI in JIRA 5.2. There is just little step to requested functionality - allow to specify in JQL something like components in (*) which would persist and appear in GUI like [ In components: All ▼]