ScriptRunner - failed script setting a Group picker field from another custom field

[Cary Watkins]

I am trying to use the below script to pull the value from one field and apply it to a single Group picker. I have seen this script in another discussion and it worked for them, but I am not sure why it is not working for me. I would like to add this script as a listener for whenever the ticket is updated. Is there any way to make the listener only trigger when a specific custom field is updated? Below is the script that is failing for me:

import com.atlassian.jira.component.ComponentAccessor
def customFieldManager = ComponentAccessor.getCustomFieldManager()
def groupManager = ComponentAccessor.getGroupManager()
def assignGroupField = customFieldManager.getCustomFieldObjectByName("Test Group")

def assignedGroupValue = customFieldManager.getCustomFieldObject("customfield_10601")
def assignableGroup = groupManager.getGroup(assignedGroupValue) //jira group
issue.setCustomFieldValue(assignGroupField, assignableGroup)

In this instance, Custom Field 10601 is where the value is currently. This is an Insight Custom field. I need to take the text from that field, and apply it as a group in the field called "Test Group".

As part of this script, is there any way to add a component that manipulates the text before it adds it to Test Group? I was wondering if I could use the 'substringBefore' function to only utilize part of the text?

[PD Sheehan · Accepted solution]

First, let's have a look at your condition:

import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.comments.CommentManager;
import com.atlassian.jira.user.ApplicationUser;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.issue.CustomFieldManager;

//cfValues['Clone']?.value != "Yes"
//cfValues['Clone']*.value.contains("Yes")
if (cfValues['Clone']*.value.contains("Yes")) {
   return false
} else {
   return true
}

def changeHistoryManager = ComponentAccessor.getChangeHistoryManager()
! changeHistoryManager.getAllChangeItems(issue).find {
   it.field == "Done"
}

I'm not sure what you intended to do with the changeHistoryManager, but since both clauses of the if() statement above include a "return" statement, the changeHistoryManager will never be executed.

In the Additional Issue Action code block "issue" refers to the new clone that is about to be created. So attempting to set the clone customfield value there will not work.

You could write additional code to change sourceIssue as part of Additional Issue Action, but it might be easier to just have a diffferent post function set your custom field value to yes.

But, reading your comment more carefully, I don't think you need the custom field. Your initial attempt to look at the changeHistory in the condition might work. Another option is to use the linkedIssueManager to look for an existing clone.

Try something like this in your condition

import com.atlassian.jira.component.ComponentAccessor;
def changeHistoryManager = ComponentAccessor.getChangeHistoryManager()

!changeHistoryManager.getAllChangeItems(issue).any {
     it.field == "status" && it.tos*.value.contains("Done")
}

You may want to replace "Done" with the actual status name (not transition).

This means, only perform this post function if the current issue has never been in the "Done' state before.

[Simon Krautwig]

Hi @PD Sheehan .Thank you very much. I was able to solve the problem with your suggestion. That actually helped me a lot and the script was very short.

Greetings from Germany,

Simon! 

[Priyanka Agrawal]

@PD Sheehan ,

Is there a way to avoid duplicate cloning without hiding the status from the view screen?

Please suggest. I'm not so good with coding.

[PD Sheehan]

@Priyanka Agrawal I would need a little more info to be able to answer fully. Every case is different. For coding to be effective, one needs to know what's already in place and exactly what's desired.

But in general terms, you can either hide the transition with a condition that looks for existing linked issues (optionally with a certain link type).

Or use the "Condition" script for the post function and skip running the post function when a linked issue already exists.

[Priyanka Agrawal]

Hi @PD Sheehan 

Thank you for such a quick response.

I have a project with workflow where when an issue is transitioned from status Build to Test, few automated tasks are created. But when a user realize that oh no the test has failed and i need to go back to status Build. So he transitions the issue back to Build and when from Build it is transitioned to Test the second time, those automated tasks are getting created again. So i would like to avoid these double creation of tasks.

To be specific, the link type is "Issues in Epic"

Your second suggestion :"use the "Condition" script for the post function and skip running the post function when a linked issue already exists" sounds good to me.

Could you please help me with this?

Hope the requirement is clear now?

Your help in this regards would be highly appreciated.

Best regards,

Priyanka

[PD Sheehan]

How are the automated tasks created? Can you share screenshots?

[Priyanka Agrawal]

@PD Sheehan : Attached the screenshots of the workflow Postfunctions through which automated tasks are being created.

[PD Sheehan]

What app is providing this functionality? It does not look like scriptrunner.

[Priyanka Agrawal]

@PD Sheehan  this is not scriptrunner but a postfunction called "Create / Clone issue(s) (JMWE add-on) Function"

[PD Sheehan]

I don't have JMWE and I'm not familiar with how it implements conditional execution.

You'll need to consult their documentation or post a new question in a topic where experts on that tool can help you.

I'm more of a scriptrunner/groovy/jira api guy (as evidenced by the post title and tag).

But basically, you need the condition to be false when an issue already exists that matches the issue that you would otherwise create.

[Priyanka Agrawal]

@PD Sheehan  Many thanks for your support.

[Dar Kronenblum]

hi @Simon Krautwig 

not sure that I understood you completely, but it seems like the custom field update didn't store the value in the database.

try to add this line to your code to store the data:

ComponentAccessor.getIssueManager().updateIssue(user, issue, EventDispatchOption.ISSUE_UPDATED, false)

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption
import com.atlassian.jira.user.ApplicationUser

def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()

ComponentAccessor.getIssueManager().updateIssue(user, issue, EventDispatchOption.ISSUE_UPDATED, false)

[Simon Krautwig]

Hi @Dar Kronenblum ,

thank you for your reply. But with the solution from @PD Sheehan I was able to slim down the whole thing. Thank you very much anyway.

Best regards.