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.

[Dzmitry — Schema Tools]

Adding to the automation suggestion above: it works well when subtasks are created by the rule itself, but it can't stop a person from manually creating a disallowed subtask type — and as noted in this thread, the change-type workaround breaks when the types use different workflows.

For the enforcement side: we're Schema Tools, a Marketplace vendor, and we built an app that lets admins define which subtask types are allowed under each parent work item type per project, with a default type, checked when the subtask is created: https://marketplace.atlassian.com/apps/3581393520/subrule-restrict-subtask-types-for-jira

[Evie Z_]

@Dzmitry — Schema Tools 

This topic is now closed as the discussion has become outdated. If you have more questions or want to continue the conversation, feel free to start a new topic. For more details on why we close older threads, check out our Rules of engagement - Atlassian Community .

Thank you for your understanding!

[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,