Add dynamic filter to other filter results

[webcapcha webcapcha]

It seems that this plugin do what i need https://marketplace.atlassian.com/plugins/com.qotilabs.jira.rich-filters-plugin/server/overview

but i'm looking for free alternatives

Basically i want to filter result of other filter. I have the filter that i use in my gadgets. And i want to have ability add one more conditions to this gadget (like affected version for example) and change it dynamically and manually to exclude items from origin filter.

I use cloud version.

Any ideas?

affects-version.jpg ‏101 KB

[Ignacio Pulgar Martín]

As you use Cloud, that specific plugin is not available to you, because it is only available for Server.

The free option you have at your disposal is using a JQL like:

<Your additional conditions> AND filter = <referenced filter name or filter id>

In example:

affectedVersion = 1.0 AND project = FOO AND filter = "The issues that matter"

Hope it helps.

[webcapcha webcapcha]

Actually i created dashboard with gadgets. So i'm not able create one more gadget or whatever and do one more conditions (affected version for example) to existed gadgets, right?

And only one way is to using search issues field and everytime add JQL query?

[Ignacio Pulgar Martín]

What you can do is:

1. save a filter like the one I suggested and edit the <your additional conditions>
2. set the newly created filter into the gadgets you want

After that, you will be able to edit the new filter with additional conditions so that your gadgets are updated accordingly.

Should you not need to add any more conditions, you can add a condition which is matched by all issues in your instance, ie:

type is not EMPTY

[webcapcha webcapcha]

It's interesting solution.

One more question. Could i make this solution more user friendly and create for example drop down field with several values (for example affected version like 1.0, 1.1, etc). And when user select something in drop down, after that immediately update gadgets result.

Is it possible?

[Ignacio Pulgar Martín]

Users can select the version from a dropdown menu once the Affects Version field is added in the basic view of the issue navigator this way:

affects-version.jpg

If multiple users need to be able to change the version, then the solution is a bit more complex, as only the filter's owner can edit the filter's query.

For making that possible:

1. Create a filter (first) with all the static options that you want to always be applied in your gadgets (ie: project=FOO AND type=story)
2. Save the filter with a descriptive name like "FOO stories".
3. Share the filter with the project(s) (All roles) that can potentially be retrieved by "FOO stories" filter.
   If projects cannot be easily predicted (ie: if the query doesn't filter by project), then you can share it with a group to which all users belong (less desirable)
4. Create another filter (second) named "My Scope" and Do Not Share it (Important!).
   Let's make it initially with this query: type is not EMPTY
5. Finally, create a new filter (third) and name it ie: "filtered FOO stories".
   The JQL that needs to have is:
   filter = "FOO stories" AND filter = "My Scope"
6. Share this third filter (filtered FOO stories) exactly like done on step 3.

For the users to be able to use the dashboard so that all its gadgets are updated with their desired conditions, each of them must create a personal (not shared) filter named exactly "My Scope" (or the name you have chosen for the second filter) like described on step 4.

Once users create a so named filter, they can edit it afterwards as many times as needed, which means the same dashboard can present different info for different users simultaneously, depending on the query they have saved on their "My Scope" filter.

[Dale Bosserman]

I am looking for the same thing except I'd like to embed the issue keys from one filter into the IN clause of another. 

For example: 

Filter 1 = labels in (Project1)

Filter 2 = parentEpic in (filter = "Filter 1")

Is there any way to get this to work? 

[Ignacio Pulgar Martín]

Unfortunately, not natively.