Automation Destination Issue not editing

[Daren Seto]

When I link and issue from one project epic [project A] to another project epic [project b]

I want Project A fields to be edited. 

I am using the destination field. but it is not working.

My rule only applies(scope) to one project [project A]. is this why it is not working? 

if i adjust the rule to be 

If I link from project b to project a. then project A is adjusted. However my workflow would be to add the link in project A and not B.

So i am looking into why it is not working

[Marc - Devoteam]

Hi @Daren Seto 

@Trudy Claspill gives an clear explanation on the issue link trigger.

But I read that your rule should impact issues in a second project.

And I see you mention the scope of the rule is set to one project, then yes, the rule should scope both projects, if this rule should make changes on an issue in another project.

[Daren Seto]

ty yes that makes sense. I should do a test linking my epic in my own project.

[Trudy Claspill]

Hello @Daren Seto 

Welcome to the Atlassian community.

Carefully review the information available in the Issue Linked trigger about identifying the "source" and "destination" issues. It is not always the case that the issue you are in when you create the link is the "source". It depends on the type of link and which one gets the Inward Description vs. the Outward Description of the link type.

Issue linked

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}}

Also look at the audit log for the rule execution. It will tell you which issues is considered the source and which is the destination. In my case I was in TTS-51 and I created a link to TTS-49 such that TTS-51 is blocked by TTS-49.

When you are looking at an issue and viewing the Linked Issues section, if #1 is the Inward Description for the Link Type, then #2 is the issue considered the "source" in the automation rule.

[Daren Seto]

ty for the explanation. i do think this might be because of the project permissions.  I can verify by using a test inside of my project.

[Trudy Claspill]

I did not notice that you mentioned the rule scope is set to just Project A.

As @Marc - Devoteam said, you will have to change the scope of your rule to be multiple project and include Project B. That change can be executed only by a Jira Administrator.

After making that change you may also need to add more conditions to your rule to check in which project the Source and Destination issues exists to ensure the rule runs only for the combination you want.