nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I have a problem with "setRequired" method behavior in scriptRunner

jose de jesus torres torres

Context: I have a custom field "customfield_10128" of type "Select" with the name "Status F1" and a custom field "customfield_10133" of type "DatePicker". I need the field "customfield_10133" to become a required field when the value of the field "Status F1" equals "Done".

To accomplish this, I use the ScriptRunner app and configured a behavior that triggers in the "Issue View" and the "On Load" and "On Change" events. This is the script I added to the behavior:

const statusF1 = getFieldById('customfield_10128').getValue().value

if(statusF1 == 'Done'){

getFieldById('customfield_10133').setRequired(true)

}else{

getFieldById('customfield_10133').setRequired(false)

}

When I open the issue to edit and modify the value of the "Status F1" field to "Done", the Chrome console shows me this result:

Time took to load the sandbox: 166087.30ms
index.js:1 Time took to call forge getFields() api: 0.30ms
index.js:1 Time took to run behaviour: 15.70ms

(4) [{…}, {…}, {…}, {…}]

[
{
"@timestamp": "2024-04-03T15:41:56.666Z",
"message": "Added new tracking event: {\"event\":\"Behaviours API call\",\"apiMethod\":\"getFieldById\",\"targetField\":\"customfield_10128\",\"count\":1,\"fieldId\":\"b99d0140-65e3-4416-9085-2db4dbea0124\",\"affectedField\":\"customfield_10133\"}",
"level": "info",
"uuid": "b99d0140-65e3-4416-9085-2db4dbea0124",
"fieldName": "customfield_10133",
"correlationId": "85566888-4315-4975-945c-a4878d5d1456",
"event": "ONCHANGE",
"view": "Issue view"
},
{
"@timestamp": "2024-04-03T15:41:56.667Z",
"message": "Added new tracking event: {\"event\":\"Behaviours API call\",\"apiMethod\":\"getValue\",\"targetField\":\"customfield_10128\",\"count\":1,\"fieldId\":\"b99d0140-65e3-4416-9085-2db4dbea0124\",\"affectedField\":\"customfield_10133\"}",
"level": "info",
"uuid": "b99d0140-65e3-4416-9085-2db4dbea0124",
"fieldName": "customfield_10133",
"correlationId": "85566888-4315-4975-945c-a4878d5d1456",
"event": "ONCHANGE",
"view": "Issue view"
},
{
"@timestamp": "2024-04-03T15:41:56.667Z",
"message": "Added new tracking event: {\"event\":\"Behaviours API call\",\"apiMethod\":\"getFieldById\",\"targetField\":\"customfield_10133\",\"count\":1,\"fieldId\":\"b99d0140-65e3-4416-9085-2db4dbea0124\",\"affectedField\":\"customfield_10133\"}",
"level": "info",
"uuid": "b99d0140-65e3-4416-9085-2db4dbea0124",
"fieldName": "customfield_10133",
"correlationId": "85566888-4315-4975-945c-a4878d5d1456",
"event": "ONCHANGE",
"view": "Issue view"
},
{
"@timestamp": "2024-04-03T15:41:56.667Z",
"message": "Added new tracking event: {\"event\":\"Behaviours API call\",\"apiMethod\":\"setRequired\",\"targetField\":\"customfield_10133\",\"count\":1,\"fieldId\":\"b99d0140-65e3-4416-9085-2db4dbea0124\",\"affectedField\":\"customfield_10133\"}",
"level": "info",
"uuid": "b99d0140-65e3-4416-9085-2db4dbea0124",
"fieldName": "customfield_10133",
"correlationId": "85566888-4315-4975-945c-a4878d5d1456",
"event": "ONCHANGE",
"view": "Issue view"
}
]

behaviours-sandbox.html:23  
POST https://hydrogen.sagittarius.connect.product.adaptavist.com/behaviours/logs?jwt=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InBsME9oSHJucnJoQzFqcC1tNlluRSJ9.eyJjbG91ZFVybCI6Imh0dHBzOi8vbWF2aS1qanRvcnJlcy5hdGxhc3NpYW4ubmV0IiwiY2xpZW50S2V5IjoiNDAxNjNjMDItOGFmMy0zNTlhLTk0OGQtYjE2ZTIwZDZhNDNhIiwiaWF0IjoxNzEyMTU4NzUzLjI3NywiZXhwIjoxNzEyMjQ1MTUzLjI3NywiaXNzIjoic3ItYmVoYXZpb3Vycy10cmFja2luZyJ9.Dj27SDNKkuETkGQi0rw88DRgcbacFDuF6YF6AQtLjlY34x9dFAKuAZ6_JksnoAIyubLWzTIYofOAxw7VPb3OVSb9lLy0SnHZ-EvYiEQMiXkrwV7QmXMnB-u5qXVOKn2qqg5mxan7A7LDAmF-j02abJFzjfVBrAEuuqAimQou7nUD50PK7FNDCqp9xZLdg2mwzkGkoq45QjiO4tQ0r_0qQ2IqpWrmMgtiptrdNoDGPpy7jmKChQoWVyviU1ET3zTa0AI4rv6A7ZheW56nncFaZs_MGCcujELIcQIegTk7pkVhZjLiNUIO0ktfi3jmSdoQAjXM82GJ9xN4GGSb2vRFEg&correlationId=85566888-4315-4975-945c-a4878d5d1456 400 (Bad Request)

	Wt		behaviours-sandbox.html:23
	Kt		behaviours-sandbox.html:23
	onChange		behaviours-sandbox.html:33
	await in onChange (async)
	(anonymous)		behaviours-sandbox.html:23
	c		behaviours-sandbox.html:23
	i		behaviours-sandbox.html:23

When I add a value to the "customfield_10133" field and then remove it JIRA does not mark it as required.

I don't understand why my script doesn't work, please can someone help me.

Accepted answers

Matt Parks

Do you have other behaviors that are triggering off of the Issue View screen? The reason I ask is that, while I only have Data Center, in my experience, behaviors only work on Create/Edit or transition screens.

If you're trying to make a field required, but you're on the View screen, I don't understand how you could then set a value on the required field if it isn't already populated.

All comments

Matt Parks

If you're trying to make a field required, but you're on the View screen, I don't understand how you could then set a value on the required field if it isn't already populated.

jose de jesus torres torres

Hi Matt, it's my first behavior on the "issue view" screen. The incident is already created and the behavior is configured to be executed when a value of the incident is changed, specifically if the custom field "customfield_10128" changes to the value "Done", if my script is executed. I added a printout of a string to debug where my script was running. Checking in the explorer console, I see that my script does run correctly and enters the condition "if(statusF1 == 'Done')", but the line of code "getFieldById('customfield_10133').setRequired(true)" It is the one that sends the error 400. In any case, if with a behavior I cannot do what I wrote in the context, do you know how else I can do it?

Matt Parks

At first I was thinking that you could create an Automation rule, but then I realized that making a field required is not an action that you can execute from Automation, so I am at a bit of a loss, unfortunately.

My guess is that you could use that functionality to set the value of a field, but making it required, if it doesn't already have a value, seems like it would cause a problem.

I'd be curious to know what would happen if there was already a value in customfield_10133 when you set the StatusF1 field to Done. Would the update work properly? If it did, that would probably be an indicator that the underlying problem is that the View screen was trying to make a field required but, since that field wasn't already populated with a value, you end up running into an impossible condition.

Another possibility would be to create an Automation rule that automatically sets a value on customfield_10133 when the StatusF1 field is set to Done. I don't know what value you would use that would make sense, but maybe you could create a dummy holding value for that purpose?

Since I don't know your process, I can't tell you what's best, but I'm admittedly a little curious to see how this could work.

Verity Blake -Adaptavist-

Hi @jose de jesus torres torres I’m sure this is something we’ve heard our ScriptRunner customers ask before and I believe @Nic Brough -Adaptavist- has an answer/can help. Thanks

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

jira

cloud

jira-cloud

field

required