|
I already have filters for "Unresolved Issues assigned to me" and "Open Issues submitted by me".
But since I often open a lot of my own issues myself, I really want to see "Open Issues submitted by me (assigned to any team other than mine)". And I thought I could do that by defining an "Open Issues Assigned to my team" filter and defining another filter that is just ("Open Issues submitted by me" minus "Open Issues Assigned to my team"). If the query engine knew that the "Open Issues" were the same set in both queries, that could be optimized out and either cached or only evalutated once. P.S. Sorry for making this comment twice, I just didn't see this issue until I had already commented on Also, it sounds like this issue hasn't made it onto the list for even 3.6, do you have any more refined idea of when you might get to this?
John,
Unfortuantely we do not have an implementation date. The best thing to do is vote for thsi issue. Thanks, Implementing this issue would assist the many people looking for product suite, sub-project, and sub-component support. Looking through the many issues on this topic, it seems that most people really actually want products.
With this feature, I could create a product version filter (eg Suite 4.0) that combines the results of my "Unresolved App X 4.0", "Unresolved Core 10.2", and "Unresolved SomeOtherSmallProject 4.2.1" filters. Thanks, Andy, for noticing the similarity with JIRA-1560. In that thread we were talking about custom SQL queries to do advance search operations, but now that I read this thread, I realize that a lot of what people want in 1560 can be accomplished by "stacking" queries as described here. (In fact, I think this solution could be adequate enough for 1560's requirements that it could even be considered a duplicate of this.)
The example in 1560 I gave is similar to Andy & John's example – we want a result set of "anything related to Version 123," regardless of whether it's Affects or Fixed-In. This would require an OR search or a "stacking" of two queries. Pipe dream: How about adding the concept of "runtime variables?" One could define a variable in the individual queries that would only need to be changed once in the whole stack, like: query 1) where Fixed-In version = var X If I then need to change X (which might be very frequent,) I would only need to do it in the stacked query settings, not in both queries 1 & 2. In fact, it could be a runtime selection on the query result screen itself, to save the user from having to go through an Edit path to change it. So I call my query "Related to Specific Version" and run it; and the result screen has a widget to pick the version. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Allow filters to be built upon other shared filters (combined filters)
Thanks for that very clear description. We have been thinking about implementing this recently (filters based on other filters, and/or/not'ed joined). Hopefully it will happen in the next development cycle.