Script runner and custom field ield with same name

Gajan Umapathy September 15, 2015

Hi,

It seems when we use a customfield name which is duplicated then the script is only checking the customfield with the lowest customfield ID. Previously  it used to check any customfiled which was available to the context of the project. We noticed the problem since we upgraded to JIRA 6.4.9 on the Script runner 3.1.4.

I know one option is obviously to rename and merge the customfields but what or our other options. Can we use a customfield ID to get the value?

 

 We currently use the below to check the value of a select list.

 

cfValues['Severity']?.value == 'Sev 1'

 

this also works:

 

cfValues['Severity'].toString().contains('Sev 1')

 

But this doesn't work:

cfValues['customfield_11760']?.value == 'Sev 1'

 

Thanks,

Gaj

1 answer

0 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 15, 2015

This is a workflow function?

cfValues is populated only from the fields associated with the issue. Are you sure that both Severity fields are not associated with the issue, even if only one happens to be on the screen?

> We noticed the problem since we upgraded to JIRA 6.4.9 on the Script runner 3.1.4.

What version were you on previously?

G September 15, 2015

Hi Jamie, Thanks for getting back. Yes this is a wokflow post-function to fast transition an issue based on the condition. Only one severity field is associated to the project we are using and on the screen. This was working fine and simply stopped working since the upgrade. Previously we were on JIRA 6.1.7 and script runner 2.1.16. Thanks, Gaj PS. I see the condition checker has been removed from your plugin. However the preview of a condition to see if it works on an issue is only available when testing the send custom email function. Is there an ability test a condition for an issue another way? The standalone condition checker was very handy before. :-) .

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 16, 2015

> This was working fine and simply stopped working since the upgrade Can you explain more how it's not working? Earlier I thought you said that it's getting the wrong custom field.

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 16, 2015

We can come back to the Condition Tester when we've worked this out.

Gajan Umapathy September 16, 2015

The condition is not being evaluated now. It script always comes with false for the check on Severity. I've tried renaming the duplicate customfield names on our QA and it works. Like I said the problem has only occurred after the upgrade. I've also confirmed that the other duplicate severity fields are not available to the context of the project we are testing. We have another customfield which is also duplicated in the name but that works fine and I'm guessing the reason for this is that customfield has a lower customfield id.

Madhusudhan Matrubai December 10, 2015

Hi Jamie, Even we are facing the same issue wherein if there are multiple custom fields of the same names but different types like "single select", "checkbox" . It throws warning - "Could not look up the type for this custom field, so we can't check this code. Possible the field doesn't exist, or multiple exist for this name"

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 11, 2015

Hi Madhu... that's just a warning to tell you that we can't offer any coding assistance. There's no possible way of telling which field you meant when using cfValues with a name. You can just ignore that warning.

Suggest an answer

Log in or Sign up to answer