Automation rule to transition User Story to Done when Tasks are Done

Question

Hi all,

Our Way of Working is to have User Stories with Tasks linked to it, not sub-tasks. I want an automation rule that works only when all Tasks that are linked to the User Story as "blocks" are closed, but if there are other Tasks linked to the User Story *not* as blocking the User Story (ex: relates to, depends on, etc) then those Tasks when marked Done will not transition the User Story to Done.

This is the rule I've written, but it will close the User Story if a linked Task "relates to" is closed to Done. What do I need to change?

Kathryn Swearingen · Answer

@Walter Buggenhout  -- I think I spoke too soon. I tried the rule and it seemed to work but then after more testing it does not appear to work. I've set myself up in a Test project and have tried all sorts of permutations but nothing is working to achieve the overall goal: When all Tasks that link to a User Story as blocking the User Story are closed then close the User Story, however if there are other Tasks linked to the User Story under a different relationship (ex: relates to) then when those Tasks close do not close the User Story. Only close the User Story when blocking Tasks close.

I'm wondering if someone can help me with understanding parts of my previous rule as per my previous comment:

What is the plain English translation of: 
Branching on JQL with:
issue IN linkedIssues({{triggerIssue.key}}) AND issueType = Story
Does this translate to "For all issues linked to the trigger issue that is of type User Story"?

And then the Lookup Issues Code: 
project = OSP AND issue IN linkedIssues({{issue.key}}, "is blocked by") AND status NOT IN (Done, "LIVE (Launched)")
Does this translate to "For all issues in the OSP project that are linked to the

And I especially need help in understanding the compare 2 values syntax: 
{{lookupIssues.size|0}} equals 0
How does this look at whatever else is linked to something and determine that they're in "Done" status?

As I've said, I'm not a developer by nature, and all I know about JQL is self-taught by reading through Atlassian's website, so I have a hard time seeing what probably comes easily to others, and do appreciate any guidance.

Kathryn Swearingen · Answer

@Walter Buggenhout  -- yes! Your answer totally helped. I re-created the rule using elements from what you shared as well as some of my rule's syntax and came up with. Then I tested it with 2 different User Stories - 1 with Tasks linked to it as blockers to the User Story and 1 with Tasks linked to it as "relates to" and both worked as expected. Thank you!

Kathryn Swearingen · Answer

Hi,

Thanks for replying! Before I move on the rule you shared, would you be able to help me better understand the rule I wrote and why it's not working for only those Tasks that are linked as blocking the User Story? I'm not a developer so writing JQL has been a brand new learning experience for me and I think this is a good one to learn from.

For example, what is the plain English translation of: 
Branching on JQL with:
issue IN linkedIssues({{triggerIssue.key}}) AND issueType = Story
Does this translate to "For all issues linked to the trigger issue that is of type User Story"?

And then the Lookup Issues Code: 
project = OSP AND issue IN linkedIssues({{issue.key}}, "is blocked by") AND status NOT IN (Done, "LIVE (Launched)")
Does this translate to "For all issues in the OSP project that are linked to the

To oversimplify things, this is the plain English way of describing what I want to do: 
When an issue of type Task is transitioned to Done then for issues linked to that Task and is a User Story, then lookup issues linked to the User Story as "blocked by" and does not have a status of Done or LIVE (Launched) and if there are no other open issues as "blocked by" then transition the User Story to Done and set the Resolution to Done and add a comment in the User Story. And if there are other issues linked to the User Story as any other relationship other than "blocked by" then don't do anything.