Can we get the underlying issue issuetype when creating a subtask in Scriptrunner Behaviours?

[Alejandro Reyes]

I have 30+ subtask types and i would like to restrict with behaviours which subtask issuetypes will be shown on the create subtask screen to the user depending on the type of the father issue.

When i tried to get the underlyingIssue object (of which i only need the issuetype) on behaviour i get a null object and after 4 hours trying different approaches i surrender.

I tried already to get the issueKey showed on the url but couldn't get to get the propper one, as the request url i got is from the scriptrunner servlet, not something like https://myJiraUrl/browse/myTaskID

Trying to get the issueType field only returns me the current value of the subtask selected, the same as the issueContext.

Is there any way to do this?

The script i'm using to do the changes is this:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.security.roles.ProjectRoleManager
import com.onresolve.jira.groovy.user.FieldBehaviours
import groovy.transform.BaseScript

import static com.atlassian.jira.issue.IssueFieldConstants.ISSUE_TYPE

@BaseScript FieldBehaviours fieldBehaviours

def projectRoleManager = ComponentAccessor.getComponent(ProjectRoleManager)
def allIssueTypes = ComponentAccessor.constantsManager.allIssueTypeObjects
def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser

def issueTypeField = getFieldById(ISSUE_TYPE)
def availableIssueTypes = []

availableIssueTypes.addAll(allIssueTypes.findAll { it.isSubTask()==false})//We add all the issuetypes that are not a subtask
//If parent issue is of type X then the subtasks will be the next ones
availableIssueTypes.addAll(allIssueTypes.findAll { it.id in [ "10213", "10210", "10208", "10207"] })

issueTypeField.setFieldOptions(availableIssueTypes)

[Alejandro Reyes · Accepted solution]

Adaptavist support told me that because of the version may be some problems when putting it on a server-side initializer script but if you put it on a field server-side script works propperly.

After trying to put it on the summary field (mandatory on the creation of any issue), i managed to made the script of @Antoine Berry work.

Thank you very much for your help!

[Antoine Berry]

Hi,

Unfortunately to my knowledge the context you get in behaviours when you "create a sub-task" is not different from "creating an issue", so you would not be able to get the hypothetical  parent issue.

It would be a nice idea to open a ticket at scriptrunner though, as I have had a similar issue when cloning an issue.

Antoine

[Alejandro Reyes]

The thing is that, for creating a subtask, you must do it from an issue. Even the create subtask windows tells you the parent issue like "Create Sub-task:IssueKey".

And when you create the subtask it autofills the field for creating the link, so it should be a way to know, at least, the id or key of the parent object of the subtask before creating it. Hopefully somebody from Adaptavist would be able to tell us if they implemented something like this...

[Antoine Berry]

Have you tried retrieving the value of the issue link ?

Anyway I think you should open a support ticket, so they consider this development in case it is not available yet. Of course let me know about it.

[Alejandro Reyes]

Yeah, but the problem is that there is no issueLink if you don't create the subtask. I want the behaviour for the create subtask screen.

It would be nice that the underlyingIssue wouldn't be null or, at least, give the issueKey of the father. I even tried to get the url from the browser but couldn't get to do it.

I rised the question to their servicedesk, so i'll wait for an answer.

[Antoine Berry]

Hi @Alejandro Reyes ,

I stand corrected, you can retrieve the parent issue type when creating a sub-task : 

def parent = getFieldById("parentIssueId")
def parentIssueId = parent.getFormValue()
def issueManager = ComponentAccessor.getIssueManager()
def parentIssue = issueManager.getIssueObject(parentIssueId)
def parentIssueType = parentIssue.getIssueType().getName()

Maybe that will help you with your script.

Antoine

[Alejandro Reyes]

Hi @Antoine Berry ,

I already tried it and parent is null, as you didn't created the subtask yet.

The field of the parent issue is empty until you create the subtask, but i want it to set the options before that happens.

The adaptavist people suggested this to me already and i didn't get it to work.

I'll wait to see if they answer me anything else.

Thanks for the help ^^

Alejandro

[Antoine Berry]

That is what I thought, but it seems that you need to specify that the id is of Long type (so ignore my previous script). I did not think this was an issue in groovy, as conversion is implicit. 

This is working on my instance : 

def parent = getFieldById("parentIssueId")
Long parentIssueId = parent.getFormValue() as Long
def issueManager = ComponentAccessor.getIssueManager()
def parentIssue = issueManager.getIssueObject(parentIssueId)
log.error("parentIssue : " + parentIssue)
def parentIssueType = parentIssue.getIssueType().getName()
log.error("parentIssueType : " + parentIssueType)

Antoine

[Alejandro Reyes]

When i try your code, i got an empty string as the first line returns no value.

When I print the parent object i get this

http-nio-8080-exec-8 ERROR admin 952x118114x1 1un4vz 10.158.116.177 /rest/scriptrunner/behaviours/latest/validatorsByPid.json [c.o.j.groovy.user.FieldBehaviours] Form field ID: parentIssueId, value: null

So when get the form value i only get an empty string.

Alejandro.

[Antoine Berry]

Ah, weird, maybe this is a version issue ? 

This is what I get :

 

It worked when I changed from 

def parentIssueId = parent.getFormValue() 

to 

Long parentIssueId = parent.getFormValue() as Long

using scriptrunner 5.4.12 on Jira 7.6.0.

[Alejandro Reyes]

It may be that.

I'm using Scriptrunner 5.5.2.1 on Jira 8 so it may be that...

At least i know what may be the problem.

Thanks a lot!

[Antoine Berry]

You're welcome, I hope you will solve this. Good luck :)

[Kac Perus]

Thanks Antoine,

referring to a parent issue while creating new sub-task worked as a charm for me as well!