Scriptrunner behavior - Component value not being set for some issue types

[Anthony Giordimaina]

I have a Scriptrunner Behavior that sets the value of the Component/s field on the Create screen for issues within a specific project; however, the component will only appear to be filled in on some of the issue types and not others. The mapping is currently set to that project with "All issues" selected.

I am using this Initializer:

if(actionName.equals("Create") ){


    getFieldByName("Component/s").setFormValue("DIG")

}

The execution history of the Initializer shows no failures, but when checking the payloads for the issue types that do not work I can see that the component field is null:

 "components": "{null/empty} (java.lang.String)",

I've verified that the field is configured correctly and appears on the Create, View, and Edit screens for the affected issue types in the project. There are no other behaviors which are used for this project, and no others that are used to control Component/s.

I have tried splitting the behavior up into multiple to see if this would change anything, but the behavior performs the same in each scenario with the same issue types succeeding and failing.

Does anyone have thoughts or insight on why this would fail or succeed only for some issue types and not others?

[Ram Kumar Aravindakshan _Adaptavist_ · Accepted solution]

Hi @Anthony Giordimaina

For your requirement, I suggest you try something like this:-

import com.onresolve.jira.groovy.user.FieldBehaviours
import groovy.transform.BaseScript
import static com.atlassian.jira.issue.IssueFieldConstants.COMPONENTS

@BaseScript FieldBehaviours behaviours
def component = getFieldById(COMPONENTS)

if (!underlyingIssue) {
    component.setFormValue(['Component 1'])
}

Please note that the sample working code above is not 100% exact to your environment. Hence, you will need to make the required modifications.

If you observe, I have used this approach to Initialise the Component/s field:-

import static com.atlassian.jira.issue.IssueFieldConstants.COMPONENTS
...
...
...
def component = getFieldById(COMPONENTS)

Because the Component/s field is a system field, it is best to Initialise it using the Field Id instead of the Field Name as you have done.

Below is a screenshot of the Behaviour Configuration:-

Below is a test screenshot for your reference:-

1. When the Create dialog is opened, by default, the Component/s field is updated, and the option Component 1 is selected as shown in the screenshot below:-

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

Thank you and Kind regards,

Ram

[Anthony Giordimaina]

As you suggested, initializing using the Field ID solved the issue.

First, thank you for your help in resolving this! I appreciate it.

Second, do you have any thoughts on why initializing via the Field Name was working for some issues but not others? I would have thought that it would work the same for all of them since the field name isn't changing. I'd like to understand the root of this so that I don't make a similar mistake in the future.

Thanks again, Ram!

- Anthony

[Ram Kumar Aravindakshan _Adaptavist_]

Hi @Anthony Giordimaina

It would depend on the conditions set for that Behaviour.

Fields like Component/s Summary, Description are System Fields. So the best practice is to initialize them using the Field ID and not the field name. This is to ensure there is no conflict with other custom field and to identify the exact system field you want to update.

Thank you and Kind regards,

Ram

[Matt Parks]

I'm not sure that this is the root cause, but the actionName variable is expecting a string, but sometimes the .equals is expecting a String but also it could just be an Object. Have you tried using actionName == "Create" instead?

Also, I don't know whether you need to specify a Guide Workflow when using actionName on an Initializer, but maybe the issue types don't share the same workflow?

I am just hypothesizing, I really don't know the answer but just throwing something at the wall to see if it sticks.