Edit ticket A when linked to ticket B by type
Asked by Sascha Wiltenburg:

Hi Community, raising this ticket as it seems I cannot establish the correct behaviour for my request (Data-Center 9.4.18), after trying 600x variations.

Case: When a ticket from Project A is being linked to Project B, it should add a label to Project A ticket only (no matter from which end the links are triggered).

This should only apply on types 'Blocks', 'Blocked by' \& 'Relates to'.

Have created this in global automation rules since it should read info from 2 projects? However although limited to those 2 projects only, somehow other projects (C/D/E) tickets are being linked as well.  

Have tried several variations and now probably over engineering it, so here it goes in a nutshell:

When: Issue linked  
Types: Blocks, Relates

If: Project is one of A or B (to enable 'No actions performed' if rule run but didn't meet conditions)

For current issue - current issue - Rule restricted to project A  
If: Project is A  
Edit field - Add label

--

For Destination issue - destination issue - Rule restricted to project A  
If: Project is A  
Edit field - Add label  

Probably made to many adjustments, but can't seem to get it to work properly.  
Any help or advice appreciated!

Regards, Sascha  

<br />

Btw 1 example (success), but another project involved?

##### Action details: {#toc-hId--1451130220}

This rule was configured with a project restriction. You can change this restriction in the 'Rule details' section. Only issues from the following projects or project types will be considered:  
GAM, REP  

#### Issue linked {#toc-hId--1461633324}

Source issue (the main branch of the rule will execute for this issue and you can access it via {{issue}}):  
GAM-4924  
Destination issue (to perform actions on this issue use a 'Related branch', you can also access it via {{destinationIssue}}):  
**DBA-2390**  

#### Issue condition {#toc-hId-1025879509}

The following issues passed:  
GAM-4924  

#### Issue condition {#toc-hId--781574954}

The following issues passed:  
GAM-4924  

#### Edit issue {#toc-hId-1705937879}

Issues edited successfully  
GAM-4924  

#### Branch rule / related issues {#toc-hId--101516584}

No related issues could be found.


Answers:
author: Bill Sheboy
body: Hi [@Sascha Wiltenburg](/t5/user/viewprofilepage/user-id/5161428)

Have you tried checking both the trigger issue and destination issue project values with a condition before the rule proceeds?

Doing that *before the branches* should eliminate the possibility of other projects causing the rule to proceed.

Kind regards,  
Bill

comments: author: Sascha Wiltenburg
body: Hi Bill, thanks for your response, appreciated! Could you clarify what you mean exactly, based on my example?

Not sure what you mean issue project values, and how to add them before?

**When** : Issue linked  
Types: Blocks, Relates

**If: Project is one of A or B** (to enable 'No actions performed' if rule run but didn't meet conditions)

For current issue - current issue - Rule restricted to project A  
If: Project is A  
Edit field - Add label

For Destination issue - destination issue - Rule restricted to project A  
If: Project is A  
Edit field - Add label

Regards, Sascha


author: Bill Sheboy
body: Immediately after your condition:
> **If: Project is one of A or B** (to enable 'No actions performed' if rule run but didn't meet conditions)

You could add a smart value condition to check the destination issue's project for the link. The project key for that issue would be this:

```
{{destinationIssue.project.key}}
```


author: Sascha Wiltenburg
body: Hi Bill, thanks again!

Having created new flow using your suggestion (on every step actually), to monitor what is exactly happening on every request \& to determine when which ticket is being treated either as 'source' or 'destinationIssue'.

Apparently it's more complex since they can change per request depending on the link-type being used, meaning when 'blocked by' is used, the source becomes the destinationIssue and vice versa.

However although I seem to have managed a proper flow and successfully tested all 6 directions between 2 projects using 'Blocks', 'Blocked by' \& 'Relates to', main issue unfortunately remains, when published to production somehow any 3rd project is able to apply on these conditions as well? (although limited to 2 projects only)

In this case, it was just simple 'Relates to', and still a SCR was being linked;

ACTION DETAILS:  
This rule was configured with a project restriction. You can change this restriction in the 'Rule details' section. **Only issues from the following projects** or project types will be considered:  
GAM, REP  
Issue linked  
Source issue (the main branch of the rule will execute for this issue and you can access it via {{issue}}):  
GAM-5413  
Destination issue (to perform actions on this issue use a 'Related branch', you can also access it via {{destinationIssue}}):  
**SCR-25116**   
Issue condition  
The following issues passed:  
GAM-5413  
Log action  
Debug message  
SCR  
Issue condition  
The following issues passed:  
GAM-5413  
Edit issue  
Issues edited successfully  
GAM-5413  
Branch rule / related issues  
No related issues could be found.  
Re-fetch issue data  
Issue data re-fetched from server successfully.  
Send Slack message  
Successfully sent Slack message

Regards, Sascha


author: Bill Sheboy
body: Yes, I also find the Issue Linked trigger a bit unpredictable regarding which issue is the trigger versus the destination (for directional link types). The only solution I have found is to use if / else conditions in the rule and handle both cases: A --\> B, and B --\> A.

You noted earlier that your rule was global (or multiple-project) scope. Is that correct?

Project-scope rules can create / clone issues in other projects, but they cannot do anything else with them: make edits, read the issue fields, etc.

That message seems to indicate your rule is project-scope only.


author: Sascha Wiltenburg
body: Hi Bill, have tried both, setting up in a single project at first, and currently running it Multiple projects scope (above audit logs).

Starting over to try with if / else conditions \& smart values like '{{issue.issuelinks.inwardIssue}}', {{linkType}}, {{triggerIssue}} etc.


Tags: data-center

issue-link

jira-software