Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Scriptrunner behaviours logic Edited

Dirk Ronsmans Community Leader May 10, 2021

Hey everyone,

I'm struggling a bit to see how the logic of Scriptrunner behaviors triggers and processes the scripts.

I currently have one behavior linked to a JSM Request Type.

On this behavior I've added several fields and each field as it's own server side script.

Now I'm seeing some strange things happening and wanted to double check on whether my understanding of a behavior trigger and execution is correct.

When I change a field on my Request Type, will it always run thu all the fields I've added in that behavior and execute the script? 

Or do the fields that I add in the behavior mean that it will only trigger when that specific field is changed? I was always under the impression that a behavior will trigger when you change the field that is listed in that behavior and only for that field.

It's now that I'm seeing some weird things happening that lead me to believe otherwise.

Or maybe even clearer. It seems like when I hit my Create button to submit my request, the request is evaluated (errors on mandatory fields) and then all the behaviors seem to trigger.

I don't have any initialiser set but it almost seems like when the validation of the request is done (mandatory fields) that the form reloads and triggers all the behaviours as if all the fields I have defined are changed..?


Anybody got some thoughts?

1 answer

1 accepted

0 votes
Answer accepted

You can use your chrome developer tool and examine all the network calls to rest/scriptrunner/behaviours/latest/validators.json  and rest/scriptrunner/behaviours/latest/runvalidator.json

Here is what I've deduced from that..

  • When you first access an issue or open a screen the validators.json api is called to get all the fields impacted by a validator base on behaviour mapping, all the server-side scripts will be executed. That means any initializer and any field server-side script. This is to get the initial state of each field.
  • Then as the fields that were found in the mapping are initialized (perhaps by default values in the initializer or by the issue value when editing) the runvalidator.json for each field is called.
  • As you make further manual changes, the runvalidator.json will continue to be called for just the fields that you change.

So the trick is, assume each server-side script will be run once with each time a screen is loaded. If you will react to changes, make sure the changes are real. For example, I have a behaviours that clears field A every time field B is edited. I don't want to have this script wipe field A each time I edit the issue and change other fields (but not B). So to protect against that, I check the value of field B against the underlyingIssue and if it's different, then I clear field A.

Something like this:

import com.atlassian.jira.component.CoponentAccessor
def fieldB = getFieldById(fieldChanged)
def fieldA = getFieldByName('fieldA')
def cfB = ComponentAccessor.customFieldManager.getCustomFieldObject(fieldB.fieldId)
if(underlyingIssue && fieldB.value != underlyingIssue.getCustomFieldValue(cfB)){
Dirk Ronsmans Community Leader May 10, 2021

Hey @Peter-Dave Sheehan ,

Interesting findings and workaround. This does throw of how I've been thinking about behaviours in general. My broad idea/understanding was that 

  • the initializer would load when you open the screen (the first time)
  • any field scripts would only run when you (manually) changed that field.

Like you mention, any time a single field is changed, only the part for that field is executed. However, when a field is loaded/reloaded it will call the initalizer (makes sense when opening to me but not after) but also all the field scripts that are in your mapping.

Now in general that doesn't seem like much of an issue and I tend to not have an issue with it because I only use my behaviours for/map them to Request Types, to assist the customer, which doesn't interfere any more afterwards.

I only noticed the behaviour because indeed a field with a specific value cleared some other fields. Then I add data to those newly cleared field. Where it goes wrong then is that when I hit the create button and the mandatory fields are checked (from the request type) which in turn returns a "you missed a field", I guess it reloads the screen and runs both the initializer and all the scripts from the mapped fields causing my newly manually entered data to be cleared again.

The way your workaround then works is by double checking the front end value vs the underlying issue value and only executing the behaviour if this really changed. Nice idea!


I did reach out to Adaptavist for this as well to get a definitive answer (besides my best educated guess) and here is what they provided me.

I can confirm that all behaviours attached to fields will be triggered when you press the "Create" button. This is how Behaviour works in front end.

Fortunately, this problem can be easily worked around by using setError() and clearError(). To do that:
1. Add following snippet to field A:

getFieldByName("Field X").setError("You need to enter a value")getFieldByName("Field Y").setError("You need to enter a value")getFieldByName("Field Z").setError("You need to enter a value")

  1. Adding following snippet to fields X, Y and Z:

if (getFieldById(getFieldChanged()).getValue() == "") {  getFieldById(getFieldChanged()).setError("You need to enter a value")} else {  getFieldById(getFieldChanged()).clearError()}

Unless all three fields have value, the user can't press the "Create" button and, thus, won't trigger the field A behaviour to clear value.


essentially it seems it would make more sense then to handle the mandatory fields yourself in the code instead of having it handled by the request type mandatory flag and thus blocking the user from hitting the create button before all is filled in. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Asked in Jira Service Management

JSM June ask me anything (AMA)

Hello Community members! We’re wrapping up the end of JSM June with an Ask Me Anything (AMA) with the Jira Service Management product team. This is your chance to ask all your ITSM questions to o...

255 views 12 14
View question

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you