Jira automation comment on issue transitioned to "Done" when blocking issue is NOT "Done"

[Ubaroz]

I am looking for a way to have Jira Automation auto-comment on a work item, when it's transitioned to "Done", if it has at least one linked working item of the type "blocking".

Essentially, I want the user to be notified when they are trying to move forward a work item which has pre-conditions, based on the built-in "linked issue" functionality. So far, results have been touch and go with many false positives and negatives.

Here is my setup:

 

My needed automation logic:

IF

[Work item A] is transitioned to "Done"

AND

[Work item A] has a linked [work item B] blocking it (linked issue: "blocks")

AND

[Work item B] is NOT "Done"

Then

Comment on [Work item A] ("Attention!
This work item is blocked by another work item and should not be marked as "Done" until the blocking work item is completed first.")

The closest I got in way of answer to this was here:

https://community.atlassian.com/forums/Jira-questions/How-to-write-a-automation-rule-so-that-when-blocked-issue-is/qaq-p/2601468#U3228194

@Trudy Claspill apologies for resurrecting this, but this is the only place where I found a reference to what I am looking for, but lacking the practical next steps.

What you wrote there is exactly what I am trying to achieve:

"...If not, with an Automation rule you would be able to detect that Issue A was in a Done status while issue B was not, and you could get a notification about that"

It seems it should be quite simple to do, but I can't seem to find the proper way to make it work.

Any help is appreciated, thank you

Ubaroz

[Trudy Claspill · Accepted solution]

Hello @Ubaroz 

The first thing I recommend is removing the Conditions from the trigger. In my experience having conditions in the trigger has not proven to be consistently reliable.

So, let us start with a Work Item Transitioned trigger that has no conditions.

In your trigger you have set it to trigger when the item transitions to Done or In Progress.

But in your text you said the requirement is when an item transitions to Done. So remove the "in Progress" value from the To field in the trigger.

Next add a Condition after the trigger for you category IN  criteria

The next condition you specified is "if it has at least one linked working item of the type "blocking""

If you look at the Linked Issues section of the transitioning issue what would the relationship to the other issues show? What is the text pointed to by the arrow in my example, above the linked issues you want to consider in this condition?

That is the text you want to select in the Related Work Items Condition in the Link Types field.

Your requirement also says "has at least one" with no other parameters on the linked items. The exact match for that would be to use "is present"

But in your actual condition you set the Condition to  "all match specified JQL" and then set the JQL to "resolution != Done". So from this and your reference to the other Question I am inferring that the condition you want is 

"at least one linked issue of link type blocking exists and is not Done"

We need to define what you mean by "not Done". Do you want to check the Status value of the linked issue? Currently you are checking the Resolution value, which is not necessarily the same as the Status.

If checking the Resolution field is what you truly want to do, then my next question is about the Scope of your rule. Notice the Flow restricted to spaces section in my image above? Does that show when you configure the condition in your rule? Does the space list include all the spaces where [work item B] items might be located? Because this condition will consider only the linked items in the spaces named.

If you need to consider linked items in spaces besides the one that [work item A] is in then you need a multi-project scoped rule. Do you already have it configured for that? If not do you know how to do that or do you need an explanation?

After this condition you would have the step to comment on the original (work item A) issue.

If the rule and this condition are properly scoped, and you have split the conditions out of the Trigger as I recommended, test the rule and see if you get the correct results.

If you don't get the correct results then we need to dive deeper into the exact results you are getting and how they don't match your expectations.

[Ubaroz]

Absolutely perfect, thank you!

What a quick and excellent answer. I made all the changes you suggested and everything works as intended.

I will mention that some of the changes you suggested, I already tried before ("Status" vs. "Resolution", using only "Done" without "In Progress", interchanging between "Blocks" and "Is blocked by" and others), but they had no apparent effect.

So, perhaps what made it work was the separation of the additional condition ("Category") into a standalone step, which is strange but I can't argue with what works (and it's excellent advice regardless). Either that, or something else I missed in my configuration. In any case, this now works, thank you so much.

Ubaroz

[Trudy Claspill]

Excellent!

I don't know why sometimes having conditions in the trigger has inconsistent results.

In this case were you also changing the Category value(s) as part of the transition? If so the trigger may have been called before the Category change took effect.

[Ubaroz]

The categories in this case are on the Space level (under Space Settings) and no, they were not being touched during transition, so this is still a bit of a mystery.

[Bill Sheboy]

Greetings @Ubaroz and @Trudy Claspill 

In my opinion and observations...

One of the reasons conditions should not be used in triggers is racetrack timing defects in rule triggers.  That is, the events which trigger rules can allow them to start a rule running before the data is stable...leading to unpredictable results for the conditions in the trigger.  In my experience, this happens often for the Work Item Created trigger, and can happen for others.  With the Work Item Transitioned trigger shown, workflow actions can impact the data...also leading to the racetrack timing defect.

Other reasons not to use conditions on triggers are the known defects specifically for conditions on triggers.  One example is using related work items or JQL conditions on the trigger when there is one-and-only-one work item match to the conditions.  That has be demonstrated to "miss" testing that one item...erroneously leading the rule to continue, or not, based upon the conditions.

Finally, when the conditions on triggers feature was added, the apparent "reason" to add the feature was to reduce audit log noise for rules which perform no actions.  However, the designers missed the point of diagnosing rule problems, and so there is no way to know why a rule did not run when there are conditions in the trigger as the log provides no clarifying information.

The mitigations for these problems are:

• never use conditions directly in triggers; add conditions separately after the trigger
• with triggers such as Work Item Created, always add a Re-fetch Work Item Data action immediately after the trigger, and the add the separate conditions following the re-fetch
• watch for community articles from Atlassian when they announce the re-architecting changes which will eventually solve these defects

Kind regards,
Bill