Restrict types of sub-tasks that can be created

[Trudy Claspill]

I am working on a Jira DC to Cloud migration. For a project there is a request to prevent creation of sub-tasks after migration, but retain all the existing project data within the project.

1. We cannot remove the sub-task issue types from the project issue type scheme, since that would require changing or moving the existing issues of those types.

2. The client does not want the issue moved to another project.

3. Changing the issues to another type (which would be acceptable) is not considered practical because of the differences in workflows, fields, screens, etc. and the volume of issues that would have to be moved.

There are several third party apps available, including ScriptRunner. I know a ScriptRunner Behaviour can be used to manage the available Issue Types on the Create Issue screen.

Can SR or any other third party app be used to affect the issue types available when using Create Child/Sub-task or Convert to Subtask?

Bonus question: Can SR or any other third party app be used to affect the issue types available when using the Move function, singularly or through Bulk Changes?

[Maciej Dudziak _Forgappify_]

I didn't test this yet, but there is a Forge module: Jira action validator (Preview), which supports workItemTypeChanged action. There is no dynamic modules yet in Forge, so there won't be any marketplace app, but, in theory, you can create a very basic forge app, basically with just a manifest and hardcode expression, docs below:

https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-action-validator/

[Olivia Medina]

Hi Trudy, this is a really interesting scenario, thank you for sharing!

Thinking out loud here: if modifying the issue type scheme isn’t an option, could you adjust the project’s permission scheme instead? Removing the Create Sub-task Issue permission for users should prevent new sub-tasks from being created, and it also blocks converting existing issues into sub-tasks.

I haven’t used ScriptRunner myself, so I can’t speak to that one directly. However, I’ve recently worked with Smart Checklist to run some automations, it could be a good alternative to replace the need for sub-tasks. It allows you to set individual item statuses and even trigger automations based on those status changes, which might help in future scenarios.

Checking back later to see what the community has to say about your case!

[Trudy Claspill]

Hello @Olivia Medina 

Thank you for your response.

Create Sub-task is not a permission in the Permission Scheme. It has the more generic Create Issue permission.

While I appreciate the Smart Checklist suggestion, that does not address the problem of needing to block creation of Sub-tasks when a Sub-task issue type must remain in the project's Issue Type Scheme.

[Maciej Dudziak _Forgappify_]

Hi @Trudy Claspill

Yes and no — for the Issue Create dialog, the UI Modification API can hide issue type options. This means that apps like Behaviours or Field Rules – UI Modifications can handle this scenario.

It’s also possible to add a Jira Expression-based validator to the Create Issue transition to prevent creating issues of a certain type.

However, when it comes to Move or Change Issue Type operations, I don't think there is currently a way to achieve the same result.

Cheers

[Trudy Claspill]

Hello @Maciej Dudziak _Forgappify_ 

Thank you for your response.