ScriptRunner / Groovy - Pass Variable to Closure to Set Radio Buttons

[Zuri Suwru]

Hey all,

While I am aware that code in closures should normally be self contained, I'm trying to find a solution to a problem I have. Here is snippet from my code:

String changingValue = body.substring(IndexStart,IndexEnd)

def result = ComponentAccessor.optionsManager.getOptions(customFieldtoUpdate.getRelevantConfig(issueObject))?.find(){
it.toString().equals(changingValue)
}

In a nutshell, "changingValue" is a String that is extracted from an email via a Mail Handler, and the "result" is an Option. As the former variable is different every time, I cannot hardcode the string into the ".equals()" check.

Normally, if I were to update a radio button field, the string alone would work. Here however we are creating an issue from scratch using the issueFactory¹, and no matter how I give the value² for the radio button custom field in this scenario, it only works if it is passed as an "Option", which I'm using the find closure for.

1.

def issueFactory = ComponentAccessor.issueFactory
def issueObject = issueFactory.issue

issueObject.setProjectObject(project)
issueObject.setSummary(subject)
//And so on and so forth...

2.

issueObject.setCustomFieldValue(customFieldtoUpdate, result)

Given that globals don't really exist, any ideas if there is a way I can pass a variable inside? If not, what alternative / workaround could you fetch the radio button option object using only a string?

Thank you for the answers in advance!

[Aron Gombas _Midori_ · Accepted solution]

After a quick look at your Groovy script, it looks OK to me. The closure should be able to access changingValue.

Please check the followings:

1. Print out the value of changingValue, to be sure that it is what you expect.
2. Print out the type of changingValue and also the type of it.toString(). Groovy has its own string type called GString, and sometimes rather unexpectedly some value are of this type. If that's the case, then make sure that you compare String with String or GString with GString!

[Zuri Suwru]

Hey Aaron,

Sorry for the late reply. After digging through a ton of documentation, I've resolved my issue by using a non-closure approach instead.

def option = ComponentAccessor.optionsManager.getOptions(customFieldInQuestion.getRelevantConfig(issueObject)).getOptionForValue(changingValue, null)
issueObject.setCustomFieldValue(customFieldInQuestion,option)

I will definitely take a look into string types next time I encounter such an issue, as I'm 100% sure no matter how I passed it in the original script, the returning value was always null, unless the string was hardcoded directly into the closure. This leads me to believe that you hit the nail on the head of the case and it wasn't a String but rather a GString.

Thank you for your response!

[Ram Kumar Aravindakshan _Adaptavist_]

Hi @Zuri Suwru

Could you please clarify if you are setting the value into the custom field before the issue has been created using the issueFactory or updating the custom field after the issue has been created, i.e. using the issueManager.updateIssue method?

If it is the former, please change your approach and update the field after the issue has been created using something like:-

def fieldConfig = sampleList.getRelevantConfig(issue)
def options = optionsManager.getOptions(fieldConfig)
def option = options.find{it.value == 'Option1'}
issue.setCustomFieldValue(sampleList, option)

issueManager.updateIssue(user, issue, EventDispatchOption.DO_NOT_DISPATCH,false)

You can refer to this Community Post for a detailed explanation.

I am looking forward to your feedback and clarification.

Thank you and Kind regards,

Ram

[Zuri Suwru]

Hey there Ram,

A ScriptRunner mail handler is creating the issue upon being triggered. No updates take place, as there is no existing issue up until the point of receiving a mail.

If it is possible, I'd like to avoid having a separate listener / automation just to update a singular radio button value, as this very same script is able to handle all other custom fields present.

[Ram Kumar Aravindakshan _Adaptavist_]

Hi @Zuri Suwru

In your last comment, you mentioned:-

If it is possible, I'd like to avoid having a separate listener / automation just to update a singular radio button value, as this very same script is able to handle all other custom fields present.

I think you have misunderstood my explanation.

Although the update method is used, it is only done once, i.e. when the issue is being created via the MailHandler.

Hence, the Custom Field is updated only once upon issue creation. When you access the newly created issue, you will see the value set for the custom field. No further modifications will take place.

You won't be able to set the values for custom fields using the issueFactory object.

You also mentioned:-

If it is possible, I'd like to avoid having a separate listener / automation just to update a singular radio button value, as this very same script is able to handle all other custom fields present.

There is no Listener or Automation involved in this.

Please refer to the working solution I provided in this Community Post for a detailed explanation.

I hope this helps to solve your question. :-)

Thank you and Kind regards,

Ram

[Zuri Suwru]

-

[Zuri Suwru]

Hey again Ram,

Thank you for your responses so far. I think we are both misunderstanding each other here, so please allow me to clarify the case a bit.

My issue is not with updating (or setting in this case) customfield values, but rather making the radio button option's variable dynamic. With text fields this is simple, as you just push the value and it will be set. Here however, the "Option" object must be found first based on the relevant string's value. Due to the latter hard-coding is not a solution.

As an example, imagine the string we use being any of the following: "A", "B", "C", "D", with the possibility that in the future there may also be an "E" and an "F", and so on and so forth. If we hardcode this (eg. by using an if/else statement for each possibility), the code will have to be updated regularly.

def option = options.find{it.value == 'Option1'}

To resolve this, "Option1" in your answer above should be a variable, but given the scope of Groovy scripts, this cannot be done easily, as values defined outside of the closure are not accessible to keep parts of the script like that self-contained.

So in a nutshell, I'm looking for a way to make either my approach or your example snippet use variables. If this is not possible, then another, dynamic solution would be preferred.

I hope this clarified my question!

Best regards,
Zuri