Jira Automation - Custom fields returning empty values problem

[Patrick Booth]

Hi,

I am having an issue with a Jira Automation rule I am trying to implement, I'm hoping some one will be able to solve this for me.

Use Case: When an engineer creates a 'Change' issue and links the related 'Work' task we want to grab the Epic assigned to the 'Work' task and assign it to the change as well.

Problem:

Our epic links are captured in a custom field with the ID: customfield_10008.  

In my automation rule I have this configuration to Edit the Issue:

{
  "fields": {
     "epic link": "{{issue.issueLinks.first.customField_10008.value}}"
  }
}

This Edit action is triggered when an an issue is linked to the Change issue and the Epic Link is empty.  However, it is not working.  The audit log gives this error:

Error editing issues

XXXX-4454 (Epic with key '' does not exist., Specify a valid value for the Epic Link (customfield_10008)).

I've added some additional logic to comment on the Issue with some additional values it is able to grab from the linked issue to test the overall concept of issueLinks is working:

Retrieved Epic from {{issue.issueLinks.first.issue.key}} and set Epic Link for CR to {{issue.issueLinks.first.customField_10008.value}}.

This partly works, the issue key is returned correctly but the customField_10008 value is returned as "".  I've tried capturing values from other customFields with the same result.   

What am I doing wrong?

Thanks

[Mark Segall]

Hi @Patrick Booth and welcome to the community!

Can you please provide a screenshot of the rule so we can gain additional context on the issue?

[Patrick Booth]

@Mark Segall - thanks for the response!

As requested here's a screen of the Automation rule.  Thanks

[Mark Segall]

Thank you for sharing... So one of the important aspects of the issue linked trigger is that you have two parts.  They describe it in the trigger itself:

Rule executes when an issue is linked to another issue. {{issue}} will always refer to the source issue, so if ISSUE-A is blocked by ISSUE-B, this rule will execute on ISSUE-B. To access ISSUE-A, use {{destinationIssue}}, and to access the link type, use {{linkType}} (e.g. {{linkType}}

So, it may be a matter of using {{destinationIssue}}

{{destinationIssue.issueLinks.first.customField_10008.value}}

[Patrick Booth]

@Mark Segall 

I had a quick look at using destinationIssue as you suggested but Jira returns invalid JSON as indicated by the red underlining in the editor.  Maybe I've misunderstood how it should be implemented?



However, I don't believe this is the issue.   My existing code is finding the right Linked issue.   I have proven that by posting a comment in the Change Issue triggering the rule with the issue ID from the Linked Issue.

Result:

As you can see it's returning the issue key, this is the correct one and what is expected, however, the value for the Custom Field is coming back as an empty string.  The same applies for other attributes such as name or ID, and with other Custom Fields.

Note:  The custom field reference is correct and the Epic Link Issue Key is populated in the Linked Issue XXXX-4455.  Verified via an API request from Postman:




Expected Result

What this rule should be returning is the following in the comment:

Retrieved Epic from: XXXX-4455: Test Work Issue for CR Automation and set Epic Link for CR to XXXX-3874: Support & Maintenance.

It should also set the 'Epic Link' to XXXX-3874.

Any other thoughts, suggestions?

[Mark Segall]

Hi @Patrick Booth - Sorry for the misunderstanding and thank you for the clarity.  Are these two issues in the same project?  I'm wondering if this is a scenario where the project scope is set to single project, but should be global or multiple project

[Patrick Booth]

Same project.  Thanks

[Mark Segall]

Have you tried without using .value?

{{issue.issueLinks.first.customField_10008}}

[Patrick Booth]

Indeed, that has been tried.  
As has trying to obtain other attributes such as field name, ID etc .  For custom fields these just come back as empty strings - standard fields seem to work OK.

[Mark Segall]

I just noticed a difference between how you're capturing key and that custom field:

{{issue.issueLinks.first.issue.key}}

vs

{{issue.issueLinks.first.customField_10008.value}}

 Can you try this?

{{issue.issueLinks.first.issue.customField_10008.value}}