How to configure subtask types for specific Issue Types

[Olivia Medina]

Hi guys, 

I have a Jira Project with different issue types (e.g. Scoping, Planning, etc) I need to be able to create subtasks for each of these issue types (e.g. Scoping Subtask, Planning Subtasks...) but I need to restrict the creation of these subtasks per issue type so I don´t allow users to create a subtask linked to the wrong issue type.

I´m thinking of including automation to check the parent issue type and make the switch to the correct one if the subtasks do not correspond to that issue type. But I would also like to create maybe a validation so from the very creation this problem is solved. Any ideas?

I really appreciate any help you can provide.

[Josh McManus]

I'm also encountering a similar issue. I have limited subtask types to aid in user experience, but two different parent issue types that inform some requirements on the relevant subtasks.

Design (standard issue type) with subtasks: Implement, Validate, Rework, and Deliver.

Story (standard issue type) with subtasks: Implement, Validate, Rework, and Deliver.

For my Rework subtask, I use a workflow validation to confirm that certain fields are required when transitioning the Rework subtask from Pending Information to Ready. However some of these required fields apply to Story Rework but do not apply to Design Rework. So to solve this problem I would need to do one of:

1. Create a Rework (Design) subtask issuetype with a separate workflow with different validators
2. Create contexts for the different required fields so they only populate Rework children of Stories
3. or Create a Pending Information to Ready transition that only applies to children of Design issue types.

The problem with #1 is that users would have to know which Rework subtask type to use with Design vs Stories, and this is a recipe for error. The problem with #2 and #3 is that Contexts and Transition Conditions don't have the capability of inspecting the Parent issuetype as a condition. I'd love to find out a way to solve this issue.

[Valerie Knapp]

Hi @Olivia Medina , welcome to the Atlassian Community and thanks for your post. 

Is there any particular reason why you have to have different subtask types for each standard issue type? Or could you just use the same subtask type and avoid to have to do this configuration?

Best wishes 

[Olivia Medina]

Hi @Valerie Knapp thank you! And yes, there is a particular reason for this project, each issue type has a specific workflow that is shared with the related subtasks.     

[Valerie Knapp]

Hi @Olivia Medina , thanks for clarifying. My recommendation would be, wherever possible, to automate the creation of the subtasks to avoid the problem of the wrong ones being created. 

https://www.atlassian.com/software/jira/automation-template-library/rules#/rule/1363678 

Please check out this rule for example. 

What you are proposing, to have some validation on the parent to determine what child is correct is likely more feasible with an app, like ScriptRunner or Jira Misc Advanced Workflows. Do you have any apps to help you achieve this? 

Best wishes

[Olivia Medina]

Hi @Valerie Knapp , 

Thank you for your assistance on this one. I'm checking the automation rule to see if it's feasible as the logic implies switching to another issue type if created incorrectly. Still, as I have different workflows per issue type, I might find an issue with the automation when two different workflow statuses must be replaced.

Thank you for the one you sent me, I need this as well as I'm creating a template board to reuse on recurrent projects with the same repetitive tasks. 

Kind regards,

[Olivia Medina]

HI @Valerie Knapp , 

As mentioned, the automation only works when the issue types have the same workflow. Otherwise, you get a warning, and the rule won´t work. I will need to rethink the logic here and maybe use the automation you suggest to autogenerate the subtasks based on the parent. 

Thank you,