nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to configure subtask types for specific Issue Types

Olivia Medina_7odufv

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.

Accepted answers

All comments

Valerie Knapp_dpp5c6

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_7odufv

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_dpp5c6

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_7odufv

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,

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:

Create a Rework (Design) subtask issuetype with a separate workflow with different validators
Create contexts for the different required fields so they only populate Rework children of Stories
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.

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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud