JQL that list more than one components

[Euller Cristian]

Dear, I'm trying to create a filter on Jira, but I'm having problems and I need your help. In my organization, we use components to represent departments. That is, an activity can be related to multiple departments. Would you like to create a filter where they list all activities that have more than one associated department, is that possible?

[Kian Stack Mumo Systems]

@Euller Cristian, 

It appears that this question has been answered already by @DPKJ. It looks like the only way to do that would be to write a complex query something like this:

component = "A" AND component IN ("B", "C", "D")

This would give you all issues with Component A AND one of the others. To get a comprehensive list, you'd actually need to write a query combining all  those combinations -  so

(component = "A" AND component IN ("B", "C", "D")) OR (component = "B" AND component IN ("C", "D")) OR (component = "C" and component in ("D"))

Additionally,  there are some plugins with enhanced JQL functionality that you might explore as well. I don't see any of them providing the functionality you're looking for, but you may want to take a look in case I missed something!

Thanks,

Kian

[Ignacio Pulgar]

Hi @Euller Cristian ,

The answer by @Kian Stack Mumo Systems is absolutely correct.

However, as your Jira Cloud instance counts with Automation natively, you may build a solution that lets you query for the number of Components in a more direct way.

Try the following steps.

Preparing a Number field

First, locate a custom field of type Number in your instance you are not currently using for any other purposes in the project which number of components you would like to track.

If you don't count with an unused number field, then you may create a new one with a generic name, like "Number" to maximize its reusability.

In this example, we are going to use the number field Story Points, just to avoid creating a new custom field.

Creating a Project Automation rule

Now, you will need to create a new project Automation rule.

Let's see how the automation will look like after following the next steps:

These are the parameters that need to be set in the When component of the rule:

Now, the if component, which sets a condition that needs to be met in order to execute the rule action:

Here we have the values in text format so that you can copy + paste them:

• First value: {{issue.components.size}}
• Second value: {{issue.Story Points}}

Once saved the previous configuration, we will set the Then component this way:

Select the field Components in the dropdown titled Choose fields to set... 

After that, type this smart value: {{issue.components.size}} and click on the Save button.

Finally, we will publish our new Automation Rule and we are done! :)

Bulk edit trick

Well, we aren't completely done yet!

Please, note that this automation rule will start storing the number of components in the number field of your choice just for new issues or issues where the Components field were edited after having set this rule.

So, just for a first and a single time, we need to edit the Components field of already existing issues so that the rule is triggered and our number field is set with the correct values.

The steps I suggest for achieving this goal are:

1. Create a new dummy component in your Jira project named DUMMY.
2. Execute a JQL like project = "Your project name" and bulk edit all issues to add the dummy component.
3. Repeat the previous step, but this time use the bulk edit feature to remove the dummy component.
4. Delete the dummy component from your Jira project.

Now, all issues in your project will have the number of components stored in the number field of your choice, and new issues will trigger the rule to calculate and store it in the same manner.

Conclusion and JQL filter

After having set the described automation rule, the Jira project where you have configured it will store the number of Components of every issue in your chosen number custom field.

Therefore, the JQL query for retrieving issues with more than one Component would be, according to the rule we had set:

project = "Your project name" AND "Story Points" > 1

Substitute Story Points with the number field you had chosen.

Of course, this solution also allows to query issues with a given number of components, which can also be combined with a specific component.

In example, the following query would return issues with exactly 3 components, being "Human Resources" one of them:

project = "Your project name" AND components = "Human Resources" AND "Story Points" = 3

Hope it helps.

[Kian Stack Mumo Systems]

That's a really interesting idea for a solution! The only thing I would caution is that keeping the automation rule up and running will quickly eat up the global automation rules unless they maintain a separate copy of the rule in each project.

[Ignacio Pulgar]

Indeed! I'd prefer your solution on most cases, as it doesn't rely on any other additional configurations. The way it combines components is brilliant!

I'd only chose my solution if:

• There were a really high number of components
• The ability to return the exact number of components were a requirement

Just to point out the potential cons of the solution you suggested:

• The filter requires maintenance, having to update component names when they are renamed, added or removed, with the risk of breaking the filter.
• The filter could become quite complex and hard to maintain in the case of a high number of components.

Interesting conversation that makes me think of new perspectives! :)

Thanks!

[Ignacio Pulgar]

The more I think of the automation rule solution, the more I like it.

The fact that it doesn't require maintenance of the filter is a strong reason for choosing it instead of the filter based in combinations. Do you agree?

[Kian Stack Mumo Systems]

@Ignacio Pulgar, 

I agree that it's a cleaner solution for the user to maintain. I guess the concerns about the automation executions can be mitigated by creating the rule in each project, but that doesn't take a lot of effort to do.

[Erik Pauli]

Great solution. But why the heck your are using the storypoints field? It takes 1 minute to create a custom field (which must not be visible in the view for that) :D

[Ignacio Pulgar]

Hi @Erik Pauli ,

The idea was to avoid the creation of a new number custom field, since the number of custom fields is the factor which impacts on Jira performance the most:

https://confluence.atlassian.com/enterprise/managing-custom-fields-in-jira-effectively-945523781.html

I have used Story Points in this case just for showing the solution with a number custom field that exists on all Jira Software Cloud instances.

Of course, you may create a new custom field for this purpose named "Number of Components", or reuse any other number field.

Another trick for getting the list of issues with at least two components would be exporting the results to CSV and find the second column named Components, so that you can filter out issues with a blank cell on that column through Excel.

Regards