• Community
  • Products
  • Jira
  • Questions
  • groovy script help to map/set one custom field value based on other custom field value chosen by user in workflow post function

groovy script help to map/set one custom field value based on other custom field value chosen by user in workflow post function


I have 3 custom fields of data types as

1) Subsystem, Select List (single choice) data type 

2) Module Owner, User Picker (single user) data type and

3) Release Prime, User Picker (single user) data type

In one of my workflow post function, Based on the "Subsystem" custom field value set, I need to map/set the respective 'Module Owner', 'Release Prime' names to 'Module Owner', 'Release Prime' fields in Jira issues as below::


case "Agent" : //if this value is updated in the 'Subsystem' custom field

ModuleOwnerValue = "Platform-Support"


case "Automation" : //if this value is updated in the 'Subsystem' custom field

ModuleOwnerValue = "Test-Automation" 




} // switch

set the ModuleOwnerValue to 'Module Owner' custom field

set the RelPrimeVal to 'Release Prime' custom field

Note: I have to use post function to map the values instead of using the SR Behaviours plug-in as Behaviours are purely client-side... if I clone issues they won't kick in. Please advice what is wrong in my script tried to achieve the same.


import com.onresolve.jira.groovy.user.FieldBehaviours
import com.onresolve.jira.groovy.user.FormField
import com.onresolve.jira.groovy.user.FieldBehaviours
import groovy.transform.BaseScript
@BaseScript FieldBehaviours fieldBehaviours
def componentValue = ""
def relPrimeVal=""

FormField dropdown = getFieldById("customfield_10016") //'subsystem' cusomt field 
def myValue = dropdown.getFormValue()

FormField formSubcomponent = getFieldByName ("Module Owner")
FormField Release_Prime = getFieldByName ("Release Prime")

log.error("---------------- subsystem---------------"+dropdown.getFormValue())
log.error("---------------- Module Owner---------------"+formSubcomponent.getFormValue())
log.error("---------------- Release Prime---------------"+Release_Prime.getFormValue())


 switch (myValue) {
  case "10030" : //Agent
 componentValue = "Platform-Support" 
  case "10031" : //Automation tool
   componentValue = "automation"
case "-1" :
   componentValue = "kmadhu"

  • I am getting the below ERROR in my groovy script written to map the custom field values for Module Owner, Release Prime based on 'subsystem' custom field value updated in a JIRA issue.

    Please advice what is wrong in my groovy script ???

    2017-02-02 17:19:45,044 ERROR [workflow.ScriptWorkflowFunction]: *************************************************************************************
    2017-02-02 17:19:45,044 ERROR [workflow.ScriptWorkflowFunction]: Script function failed on issue: INT-2012, actionId: 1, file: <inline script>
    java.lang.NullPointerException: Cannot get property 'customfield_10016' on null object
    	at com.onresolve.jira.groovy.user.FormField.getFormValue(FormField.groovy:145)
    	at com.onresolve.jira.groovy.user.FormField$getFormValue.call(Unknown Source)
    	at Script5285.run(Script5285.groovy:13)
    	at com.onresolve.scriptrunner.runner.ScriptRunnerImpl.runStringAsScript(ScriptRunnerImpl.groovy:156)
    	at com.onresolve.scriptrunner.runner.ScriptRunner$runStringAsScript$5.call(Unknown Source)
    	at com.onresolve.scriptrunner.canned.jira.utils.CustomScriptDelegate.doScript(CustomScriptDelegate.groovy:48)
    	at com.onresolve.scriptrunner.canned.jira.utils.CustomScriptDelegate$doScript$4.call(Unknown Source)
    	at com.onresolve.scriptrunner.canned.jira.workflow.postfunctions.CustomScriptFunction.doScript(CustomScriptFunction.groovy:43)
  • Manju


1 answer

You're using behaviours API in a workflow function.

Your problem is you want some logic to happen to set values in response to whatever. You are using a behaviour script to achieve that.

But you also want the same logic when creating issues programatically.

So you need a workflow function or listener.

To avoid maintaining the logic twice you abstract out your hard-coded lists.

You need to structure it in such a way that one class deals with the mappings, and you have a script for behaviours, and a script for post-functions.

I can add if (actionId == 1) in my create post function and execute the below posted code/logic to get the module owner, release prime field values based on the subsystem field values set. But actionId is same for both create and clone issue operations as I observed so far.

Is this same behaviour api script used in my validation script, will not work in post function?

In the error posted INT-2012 Jira issue is a cloned issue created thru my groovy script in one of the other post function triggered during another issue transition(I,e Eng Assigned to Fixed) other than 'Create to Eng support' transition defined in my workflow, where iam triggering this new behaviour api script.

Why this Null pointer exception is coming when I try to get the subsystem custom field value even though it has specific value set during a clone issue in my groovy script used?

Al'so can you please share some tips on how to abstract hard coded values used in both behaviours, post function shared. So that it helps me take care of code maintainability in multiple places well.

Please advise... thanks.


I wrote my post function using groovy script instead of Behaviour API script as below:

import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.customfields.option.LazyLoadedOption
Issue issue = issue
String componentValue = ""
String relPrimeVal=""
def optionToSetId = null 
def componentCF = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Subsystem")
def selectedComponents = issue.getCustomFieldValue(componentCF)

def subSystemCF = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Subsystem")
selectedComponents?.each { LazyLoadedOption it -&gt;
    def optionToSet = 	ComponentAccessor.getOptionsManager().getOptions(subSystemCF.getRelevantConfig(issue)).find {option -&gt; option.value == it.value}
    optionToSetId = optionToSet.optionId
def componentCF0 = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Release Prime")
def selectedComponents0 = issue.getCustomFieldValue(componentCF0)
def componentCF13 = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Module Owner")
def selectedComponents16 = issue.getCustomFieldValue(componentCF13)
switch (optionToSetId) {
  case "10030" : //Agent
 		componentValue = "Platform-Support"
     	relPrimeVal=	"Ser-release"
  case "10031" : //Automation tool
   		componentValue = "automation"
     	relPrimeVal=	"Ser-release"
case "-1" :
   		componentValue = "kadhu"
     	relPrimeVal=	"Cli-release"
issue.setCustomFieldValue(componentCF13, componentValue)
issue.setCustomFieldValue(componentCF0, relPrimeVal)


Please let me know if anything wrong in this post function script written to achieve the same job as Behaviour validation script used during Create Issue transition to trigger for Auto Clone JIRA issues using my other groovy script called.

In this 'Module Owner' and 'Release Prime' custom fields are User Picker single choice data types and Subsystem is of Select List of single choice.  

Your review comments are appreciated ... 

But problem is whenever new subsystem added into my project, I end up with modifying both Behaviour API script + this new post function script - maintainability will be question for me - Please advice any other alternate best way to do the better maintainability of my these 2 scripts used in my project workflows.  

As I said, move the logic of the switch statement to a utility class under your script root, and use it from both behaviours and the workflow function.

Do you even need a behaviour at all? The point of behaviours is it will make the change as users are editing the form, then the user can keep that or change it. If you are just overwriting their choice you should not even show this field on the screen.


Do you even need a behaviour at all? My answer is Yes OR No smile

When user creates the parent JIRA issue using Create screen/form, let behaviour be used, user can keep that or change it. But as I have introduced a post function now for 'Clone Issues' only.

is there any condition check can be added to hit this post function only for "Cloned Issues" but not for JIRA issues Created using form? 

 I observed actionId is "1" for both Create and Clone issues get created in this post function, where I thought of adding if (actionId != 1) { trigger my above posted post function} - But not possible.  

do you any suggestions to avoid this overwriting user choices???


One more doubt, where I can find this utility class under your script root path???

I know only Add-ons->BEHAVIOURS and Add-ons->SCRIPT RUNNER options as below.



  • Manju


Also can you please review the post function script posted it once. Thanks in advance.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 29, 2018 in Jira

How to set up an incident workflow from the VP of Engineering at Sentry

Hey Atlassian community, I help lead engineering at Sentry, an open-source error-tracking and monitoring tool that integrates with Jira. We started using Jira Software Cloud internally last year, a...

1,121 views 0 8
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you