Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

×
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Limit sub-tasks

I have ScriptRunner with Jira Data Center.   Has anyone figured out a script that can limit which sub-tasks my user can choose from based on what Issue Type they have created. Not all my sub-tasks are appropriate for all the issue types on my project. Atlassian indicates they do not support this, so I was hoping I could script something.  I'm terrible with scripting so I really need something with detailed instructions if you can help me.  I have 3 issue types (A, B, C)) and I have 3 sub-task types. (a, b, c).  I want to limit each Issue Type so a user can only pick the same sub-task type (Issue Type A allows creation of only sub-task a, Issue Type B allows creation of only sub-task b, Issue Type C allows creation of only sub-task c.)  Help?? 

1 answer

0 votes
Radek Dostál
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Aug 18, 2022 • edited

That's something that needs to be done by behaviours as Jira otherwise doesn't support this in any way (other than workflow errors).

 

Working with these 2 as inspiration:

 # https://scriptrunner.adaptavist.com/6.20.0/jira/recipes/behaviours/restricting-issue-types.html

 # https://docs.adaptavist.com/sr4js/6.25.0/features/behaviours/behaviours-examples/sub-task-default-field

 

I tested the following which seems to work:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.config.IssueTypeManager
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.issuetype.IssueType
import com.onresolve.jira.groovy.user.FormField
import static com.atlassian.jira.issue.IssueFieldConstants.ISSUE_TYPE

import groovy.transform.BaseScript
import com.onresolve.jira.groovy.user.FieldBehaviours

@BaseScript FieldBehaviours fieldBehaviours

Long parentIssueId = null

FormField parentIssueIdField = getFieldById("parentIssueId")
if (parentIssueIdField != null && parentIssueIdField.getFormValue() != null)
parentIssueId = Long.valueOf(parentIssueIdField.getFormValue().toString())

if (parentIssueId == null || underlyingIssue != null) {
//Either, this is a not a sub-task; or, it already exists - do nothing
return
}

IssueManager issueManager = ComponentAccessor.getIssueManager()
String parentIssueTypeName = issueManager.getIssueObject(parentIssueId).getIssueType().getName()

IssueTypeManager issueTypeManager = ComponentAccessor.getComponent(IssueTypeManager)
Collection<IssueType> allIssueTypes = issueTypeManager.getIssueTypes()
List<IssueType> allowedIssueTypes = new LinkedList<>()

switch (parentIssueTypeName) {
case "Task":
allowedIssueTypes.add(allIssueTypes.find {
it.getName() == "Task Sub-task"
})
break
case "Story":
allowedIssueTypes.add(allIssueTypes.find {
it.getName() == "Story Sub-task"
})
break
case "Feature":
allowedIssueTypes.add(allIssueTypes.find {
it.getName() == "Feature Sub-task"
})
break;
default:
//do nothing, underlying parent issue is not listed
return
}

FormField issueTypeField = getFieldById(ISSUE_TYPE)
issueTypeField.setFieldOptions(allowedIssueTypes)

 

Test set up was just a custom Behaviour, mapping to the project (all issue types), and above is an initializer.

 

Needless to say, I recommend not going down this route, because maintaining all of the different groovy scripts can be a nightmare, and they are very difficult to find when they start misbehaving.

Suggest an answer

Log in or Sign up to answer