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 P 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.