Edit ticket A when linked to ticket B by type

[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

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

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

Destination issue (to perform actions on this issue use a 'Related branch', you can also access it via {{destinationIssue}}):

DBA-2390

Issue condition

The following issues passed:

GAM-4924

Issue condition

The following issues passed:

GAM-4924

Edit issue

Issues edited successfully

GAM-4924

Branch rule / related issues

No related issues could be found.

[Bill Sheboy]

Hi @Sascha Wiltenburg 

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

[Sascha Wiltenburg]

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

[Bill Sheboy]

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

[Sascha Wiltenburg]

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

[Bill Sheboy]

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.

[Sascha Wiltenburg]

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.