How can I get field from linked issue.

[Juan Pablo Cabrera]

Hey there!

I'm creating an automation rule for one of my projects an I need some advice. I need to get a field from an issue from another project. Let's say its JS 66 (just for this example).

And I'm working on the issue named IVN 12. I Need to retrieve a date (in IVN12) from a custom field on the issue JS66.

I'm creating the rule:
Trigger: Issue Link -- (all links)

Then, Edit Issue:
Field to modify: Target Release Date, then this is my query:  

{{destinationIssue.Target Release Date}}

And that is it.


The problem with what I'm doing here is that the issue that is being modified is JS 66 and I want to modify IVN 12!!

Please help me!!! I want to modify IVN 12 with the date of JS66 not the other way!!!

Thanks in advance!

[Trudy Claspill]

Hello @Juan Pablo Cabrera 

The Issue Linked trigger is a special trigger because linking issues involves two issues.

Only one of the issues will actually trigger the rule. That issues is referred to as the "source" issue and can be referenced in the rule with the {{issue}} or {{triggerIssue}} smart value.

The other issue in the pair is referred to as the "destination" issue and can be referenced with the smart value {{destinationIssue}}.

The challenge comes in understanding how Jira determines which is the source and which is the destination.

Most issue links create a relationship that indicates the issues are not interchangeable in the relationship, such as "parent" and "child", or "clones" and "is cloned by", or "blocks" and "is blocked by". These labels are used in the Inward Description and Outward Description of the link types:

When you look at issues you see those labels in the Linked Issues section

When you "read" the information you order it as "1 2 3"; i.e.

CS-85 "blocks" CS-22

CS-85 "is blocked by" CK-35

For the Automation Rule Issue Linked trigger, the issue (CS-85) that shows the Outward Description ("blocks") in the Linked Issues section is considered the "source" issue, regardless of the issue from which the link is being created.

Let us say that I was viewing issue CS-85 and I created the link to CS-22 with the relationship as shown: CS-85 blocks CS-22. Then the rule would be triggered by CS-85.

Now let us say that I was viewing issue CS-85 and I created the link to CK-35 with the relationship as shown: CS-85 is blocked by CK-35. Even though I am creating the link while viewing CS-85, it is CK-35 that will cause the rule to be triggered because CK-35 is where we would see the Outward Description (blocks CS-85) displayed.

That is a lot to absorb.

Take that information and look at the link you created between IVN 12 and JS 66. Which one shows the Outward Description of the link relationship? I bet it is JS 66.

The one caveat to this logic is when the Outward and Inward descriptions are identical, such as "relates to". In that case, the issue from which the link is being created is the source that triggers the rule.

[Juan Pablo Cabrera]

Hey @Trudy Claspill

Thanks for all the information!!
I see what you mean by "is blocked by" and "blocked". Never the less, I'm still unable to correctly retrieve the field from the Issue I want.

When I look into the issue, I see that JS66 blocks IVN 1200 and following what you told me I'm using {{issue.Target Release Date}} but it's not working.

[Trudy Claspill]

Hello @Juan Pablo Cabrera 

A useful debugging tip is to use the Log action in your rule to print into the rule execution log the values of fields, calculations, and any other smart values of interest in your rule. That can help you determine if you are getting the values you expect.

Can you please share the output that is in the rule execution log for the execution of the rule?

Also can you please share screen images that show your entire rule and the details of each step in the rule?

And lastly can you share a screen image of the issues involved to the extent that the name of the Target Release Date field is visible? Smart values are space and capitalization sensitive, so I'd like to see how the field name appears in the issues.

[Trudy Claspill]

From your original post:

I'm creating the rule:
Trigger: Issue Link -- (all links)

Then, Edit Issue:
Field to modify: Target Release Date, then this is my query:  

{{destinationIssue.Target Release Date}}

And that is it.

The problem with what I'm doing here is that the issue that is being modified is JS 66 and I want to modify IVN 12!!

And from your most recent response:

When I look into the issue, I see that JS66 blocks IVN 1200 and following what you told me I'm using {{issue.Target Release Date}} but it's not working.

The relationship you are establishing in your link is JS-66 blocks IVN-1200. Therefore JS-66 is the issue triggering the rule.

Based on your last update it appears that your rule structure is now:

Trigger: Issue Link -- (all links)
Action: Edit Issue
  Field to modify: Target Release Date  
  Value: {{issue.Target Release Date}}

The problem with this is that the Edit action is being applied to the triggering issue - JS-66. Actions are applied to the triggering issue unless you change the rule's focus to a different issue.

You need to change the issue focus to the other issue in the issue link pair - the "destination" issue.