Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,366,449
Community Members
 
Community Events
168
Community Groups

[Automation] linking linked issues

Alexey Rising Star Sep 09, 2022

Hey, failed to configure it right, or maybe it's impossible? 

Situation:

issue1 causes

  • issue2
  • issue3

At some point issue2 got blocked by new issue4. 

Technically, that means, that issue1 also blocked by issue4. Especially if issue1 is located in JSM, while 3 other issues are in internal Jira projects.

My team asks for automation, to link issue 4 and issue 1 as soon as 'blocked' link appeared.

Currently i'm linking task to itself (trigger issue), and i cant understand how to append to linked's issue other links. 
asdasd.png

2 answers

Hi @Alexey

For inward blocking use:

The following rule will link "issue 3" to "issue 1" when it is linked from "issue 3" to "issue 2".  i.e using "blocks"

Block.png

Colloquially: Your third issue blocking the second issue will be linked to the first one if the link "is blocked by" is created from the third issue towards the second.

For outward blocking use:

The following rule will link "issue 3" to "issue 1" when it is linked from "issue 2" to "issue 3". i.e using "is blocked by"

blocked outwards.png

Colloquially: Your third issue blocking the second issue will be linked to the first one if the link "is blocked by" is created from the second issue towards the third.

This should give you a preliminary idea. Feel free to experiment and test. If you need help, let me know.

Cheers,
Patrik

Alexey Rising Star Sep 13, 2022

@Patrik Korovsky  thanks for the reply, i wan unable to reproduce your automation. 

First of all, if i enable both, they run both, if i make one, then either is blocked by / blocks will not work

simul.png

 

Secondly, it just copy links between 1 & 2 into a 3rd task. Not 3 & 2 link into a 1st one. 

wrong link.png

Hi @Alexey

Sorry to hear the automation did not work for you. I have not tested it.

So I tried testing it in hopes of finding the problem:


First I tested the automation that links "blocker" with "original task" when linking from "blocker" to the "this task is caused by" ticket. The test was performed using only the following automation, no others.

Automation:

inwards_automation.png 

Testing steps:

  1. I created the "original task" and "this task is caused by" and linked them (does not matter how)

    test_1_inwards.png
  2. I created the "blocker" and linked it to "this task is caused by"

    test_2_inwards.png

Result: Working as expected

Initially, only the first and second tickets were linked. When the "Blocker" was linked to the "this task is caused by", it was also linked to the "Original ticket". It copied the links that existed in "this task is caused by".

The idea/goal was to copy the link that the second ticket has to the third.
"3" is linked to "2", then "3" copies the links from "2".

First ticket:

Original_task_outwards.png

Second ticket:

Caused_by_outwards.png

Third ticket:

Blocker_outwards.png

Conclusion:

In doing so, I found that this automation is sufficient for both cases of linking from the second ticket to the third and vice versa. This should work with an infinite number of blockers.

The automation adds all linked tickets with link either "blocked" or "is blocked by" in addition to the one you add. Essentially following the blocking logic.

Note that this automation copies ALL linked issues from one ticket to another, not only the "blocked" issues. This does not strike me as a problem because tickets are inherently linked by being blocked, so logically they are linked in these other ways. Potentially this could be avoided with "IF" conditions and other "THEN" actions, but that would require more time on my part or someone really adept at this.

Please try again, it worked correctly for me. It is possible that the second automation interfered with the first one.


More on how I intended it and how I understand it.

In "when" we define that this automation should work for both "blocks" and "is blocked by".

  • The issue link trigger for "When" always uses the source in link types, in our case "blocks"

In "Then" we define that the ticket we are editing is the destination issue

  • The automation always edits the source (blocks - link type) to match the already linked tickets in the destination issue (is blocked by - link type). This is why it does not matter if we perform an inwards or outwards link type.

Logic (Source) explanation

  • If we link the 1st issue to the 2nd issue by "is blocked by", and then the 2nd issue to the 3rd issue by "is blocked by"
    • The 3rd issue is the source, because in our operation it acquires the link type "blocks"
  • If we link the 1st issue to the 2nd issue by "is blocked by", and then the 3rd issue to the 2nd issue by "blocks"
    • The 3rd issue is the source, because in our operation it acquires the link type "blocks"
  • If we link 1. -> 2. -> 3. <- 4.
    • Then the already existing "blocks" 1. and 2. in 3. are copied to 4. because we are copying the destination to the source, in this case we are adding a blocker (source) 4. to the issue 3. (destination).
      • In doing so, the automation repeats and activates 3., because our automation is triggered by "When: Issue linked - types: Blocks"
        • 4. is then updated with all existing destination's of 3., in this case 2. and 1.
0 votes
Jack Brickey Community Leader Sep 09, 2022

Hi @Alexey ,

trying to follow here. In looking at this it seems that the circled bit would be trying to add links that already exist? In other words it seems that "for linked issues" that exist in the trigger issue you are the trying to link the to the trigger issue. I may need to try this but before I do maybe you can explain exactly your goal?

Alexey Rising Star Sep 09, 2022

Hey, my goal is to link new blocker to existing 'original' task. 

Scenario: 

  1. Client via JSM creates a bug ticket 'cannot change email'. (issue1)
  2. JSM agent validates the bug and escalate it to internal Jira development project (issue2)
  3. Jira Project manager processing newly created Jira issue and decided to link it 'blocked by' with already existing feature change, which blocks work on that reported bug. (issue3)

Issue1 is dependent on issue2, meanwhile issue2 is blocked by issue3. 

So to resolve Issue1, you need to solve issue3, then issue2 and then report to the customer to validate the solution on issue1. 


Right now, agents cant at glance see all dependencies in issue1, they see only "issue2 Caused by issue1" 

They ask me to add an automation, which will add "issue1 blocked by issue3" as soon as someone set's "issue2 blocked by issue3" as issue3 in fact blocks both of them. 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events