How to get list of Linked issue keys based linked issue custom field value?

[Suresh]

Hi Team,
On current issue.
I have a field called 'Liked Issue Keys' and it should display only linked issue keys with comma separated values based on linked issues custom fieldvalue(check box-A)= Yes.

Where were linked issues (custom field )checkbox = Yes, then the 'Linked Issue Keys' should only show those issuekeys.

Another custom field(check box-B)  on current issue, should be checked automatically if 'Linked Issue Keys' !=null and if it is null and automatically unselect the checkbox-B.

Regards,

Suresh

[PD Sheehan · Accepted solution]

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)){
   fieldA.setValue('')
}

[Dirk Ronsmans]

Hey @PD 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.