Can I get a count of specific subtasks when an issue is moved to a designated status

[Phillip Talbot]

So my problem is this:

I want to know how many "eng feedback" subtasks QA has made per parent ticket when the parent is in X status.

Is this possible with using JQL and not a tool like script runner?

Any help would be appreciated

[Stephen Wright _Elabor8_]

Hi @Phillip Talbot 

With JQL, you need to either have a field value to refer to, or have a JQL function which references the required need.

You can do this with a field value in Jira Cloud without an app, although it will required a custom field and an automation rule.

You'll need to be a Jira Admin for this.

Custom Field:

• Go to Jira Settings > Issues
• On the left-hand side, select Custom Fields
• Press the blue Create Custom Field button, and select the Number Field
• Give the field a name (eg. Count of Sub-Tasks) and press Create

I'd either not have this field on a screen, or only add it to a View screen (via Screen Scheme operations). You don't want this to be manually editable from an issue's view.

Automation Rule:

• Either...
  • Project: Go to Project Settings > Automation or...
  • Global: Go to Jira Settings > System > Automation Rules
• Press the blue Create Rule button. Then for the rule...
  • Trigger: Select Issue Transitioned. Enter the required status parameters.
  • Action: Select Edit Issue. Add your custom field, and in the box enter this smart value: {{issue.subtasks.size}}
• Give the rule a name, and activate it.

^ This will then count the number of sub-tasks below an issue when transitioned to the appropriate status. You can then reference it in JQL like any other number field.

Remember with global automation rules there is an execution limit per month, which is different depending on which plan you're on. Project executions however are almost unlimited.

Ste

[Amir Katz (Outseer)]

@Stephen Wright _Elabor8_ idea of using automation and the issue.subtasks.size is a great solution.

But, IMO, it needs to be tweaked as follows:

1. The trigger for the automation should not be 'issue transitioned', as adding sub-tasks can happen at any time and is neither considered a workflow transition nor related to any transition.

Instead, the trigger should be either the 'issue updated' event, or a schedule (run every N minutes/hours/etc.).

2. Then you add a condition that the issue is in status X, and only then you update the custom field.

One more minor tweak: while a number field is the correct field type, Jira treats number fields as floating point and will display the value as 2.0.

So I would choose instead a short text field which Jira does not format in any way.

Amir

[Stephen Wright _Elabor8_]

Hi @Amir Katz (Outseer) 

Some good ideas above!

The rule could be tweaked depending on the scenario, the original answer was specific to the question - but alternatives should be tested, to ensure it works from each different user's need.

I would recommend being careful with the Issue Updated trigger though - especially if this is a global rule. Free/Standard plans only get a certain number of global executions per month - and an Issue Updated trigger is going to activate a lot.

Ste

[Amir Katz (Outseer)]

Good point! In our Jira, all the automations are per project and not global, and each has very specific conditions.

So I wonder about this "global execution" - is this counting the number of times the automation was invoked or only the cases where the actions were performed after the "if" clause in it was true?

[Stephen Wright _Elabor8_]

Hi Amir,

An execution is counted if the rule is triggered - regardless if an action is taken or not.

---

That's why for global rules I'd recommend using triggers which are more specific, or which are controlled - such as...

• Field Value Changed, as it's specific to one field - not all fields
• Issue Transitioned - and populating the to/from statuses - so it's at a specific point in the flow of work
• Scheduled / Manual - as these aren't reliant on Issue updates, which can vary day-to-day

...rather than Issue Updated, etc - which can trigger a lot.

---

If you do need a number of global rules, I'd also consider if having a Premium or Enterprise plan is best - due to the number of global executions you get:

• Free = 100/month
• Standard = 500/month
• Premium = 1000, per user, per month (i.e 200 users = 200,000 executions)
• Enterprise = Unlimited

Ste

[Maria Andrea Famini]

Hi @Stephen Wright _Elabor8_ , if we only need the count of a specific subtask issue type and not all subtasks types, how do we get that? instead of {{issue.subtasks.size}}

[Stephen Wright _Elabor8_]

Hi @Maria Andrea Famini 

This seemed to work for me:

• Trigger: <<Trigger Here>>
• Action: Lookup Issues
  • issuetype = <<Sub-task Issue Type>>
• Action: Edit Issue
  • <<Field>> = {{lookupIssues.size|0}}

^ The Field above is a numeric field.

Lookup is a more dynamic option when you have custom information to include.

Ste

[Maria Andrea Famini]

Thank you Stephen,, will try this. 

[Gökçe Gürsel {Appfire}]

Hi @Phillip Talbot ,

You can use the Enhancer Plugin for Jira for this.

It has a custom field called Status Counter that does the exactly what you're asking for: Counts the number of times the issue is in that particular status.

This custom field can be used to sort or search in issue navigator.

Enhancer Plugin for Jira has many more custom field types that can fit your different requirements.

Please let me know if you have further questions.

Regards,

Gökçe

Please note that I'm one of the members of the Snapbytes team.

[Amir Katz (Outseer)]

I don't think that this is the correct response. @Phillip Talbot asked for a count of sub-tasks, not for the # of times an issue made a transition to a specific status.