Automatically block parent ticket if child is blocked

[motherg]

Hi all,

I was wondering if there was anyway to automatically block a parent ticket (epic in this case) if a child ticket is blocked? Specifically, if a child ticket has a link of "blocks/blocked by" (as opposed to adding a flag), can the parent Epic automatically have a link added to the other Epic that the other child ticket belongs to? These different epics and stories would be in different projects.

I feel some sort of better example might be needed as it's gnarly to explain:

Given Child A belongs to Parent A (in Project 1)

AND Child B belongs to Parent B (in Project 2)

When I add a link that states Child A blocks Child B

Then Parent A automatically gets a link to say there's a blocker in Parent B

What do you reckon? The reason for this is that in the Plans/Advanced Roadmap, if you're looking at a higher flight level where you only need to go down as far as an Epic, you can't see the fact that some of the children are blocked, so you have a misleading picture.

[Bill Sheboy · Accepted solution]

Hi @motherg 

First thing, well done in your clear explanation of the scenario!

I believe that would be possible using an automation rule, triggered on the issue linking, and using conditions and branching to update the correct epics.

This rule would need to be multiple-project or global in scope as it is modifying multiple projects.  Such rules are managed by Jira site admins, so please talk to your admin for help.

I suggest trying to create the rule, and if you run into challenges, post images of your rule and explain what is not working as expected so the community can help.  To get you started on creating your rule, please refer to these documentation and example sources:

• https://www.atlassian.com/software/jira/guides/automation/overview#what-is-automation
• https://www.atlassian.com/software/jira/automation-template-library#/rule-list?systemLabelId=all&page=1&pageSize=20&sortKey=name&sortOrder=ASC
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/
• https://support.atlassian.com/jira-software-cloud/docs/use-advanced-search-with-jira-query-language-jql/

Kind regards,
Bill

[motherg]

Thanks Bill, it's good to hear that you think it might be possible. I'll have a dig in to it and see where I get to (and report back). Fortunately I am an admin so I should be able to do a lot of it myself.

[motherg]

@Bill Sheboy we haven't managed to get this to work unfortunately, there doesn't seem to be a way to trigger the parents to link based in the act of a child being linked.

[Bill Sheboy]

I think you can still use the Issue Linked trigger for that one.  For your scenario(s), the key is which issues are checked / branched to.

If you post images of your current rule and audit log details, that will provide content to make adjustments.  Thanks!

[motherg]

We'll give it a go again @Bill Sheboy , we didn't save it as we couldn't complete the logic.

[motherg]

Hi again @Bill Sheboy - we're still persevering with this and have gotten this far (we thought this would at least return the Parent issue to the log, but it doesn't [see second screenshot]).

What we really don't understand is how to then get from that list of the Parent of the linked issue, to go and find the Parent of the issue on the other end, and then create a link.

Any thoughts would be greatly appreciated.

[Bill Sheboy]

Thanks for that information about your rule.

As a reminder, your rule will need to be multiple-project (or global) in scope because it is attempting to access issues in more than one project.  Please ask your Jira Site Admin to help as they will need to modify the rule settings.  I recommend using multiple-project to limit the impact of this rule.

Next, if you review the details of the Issue Linked trigger, you will see that the {{issue}} (or {{triggerIssue}} ) refers to the one which started the rule and the {{destinationIssue}} refers to the one which was linked.

And so their respective parents are {{issue.parent.key}} and {{destinationIssue.parent.key}}

With that information your could could be improved, removing the lookup issues action to just use branching.  For example:

• trigger: issue linked, of the type desired
• condition: issue type is Story or Task
• related issues condition: Parent exists
• smart value condition: (to check if the destination issue has a parent)
  • first value: {{destinationIssue.parent.key}}
  • condition: does not equal
  • second value: leave this as Empty
• branch: to parent (of the trigger issue)
  • action: Link Issue with the correct type to {{destinationIssue.parent.key}}
  • To use the smart value for the linking, type it into the field, and when it appears below the field, select it.

Please note well: if your links have direction (e.g., Blocks and Is Blocked By), ensure the correct direction is selected in that last rule step.

[motherg]

That's worked! I couldn't understand it, but fortunately my colleague is way more aufait with the automation stuffs than I am (the smart fields bit especially, I really need to get my head around that). Thanks for the help!

[Bill Sheboy]

Awesome; I am glad to learn that helped!

Now that it works, I recommend reviewing it with your colleague so a couple of people on the team understand the rule.  That will help with maintaining it in the future.

Please consider marking this question as "answered" to help others with a similar need find solutions faster.  Thanks!

[motherg]

I don't understand it myself yet @Bill Sheboy😅

[Bill Sheboy]

Please let me know if there is something specific about it you would like me to try to explain.  The "tricky" part with link-related rules is often the link direction.  Thanks!