Automation problem - Taking action against linked issues with a delete trigger

[Troy Parish]

I have an automation rule in place which moves statuses of blocked issues, depending on the status of the issues that block them.

When any issue is transitioned, the rule checks to see if it has any other issues that it's blocking. If the original issue is blocking other issues, and it's moved to a non-resolved status, then the rule transitions all issues that are blocked to the "on hold" status.

If the original issue is blocking other issues, and it's moved to a resolved status, the rule checks for issues that were blocked by the original, and that now are only blocked by other issues that are in a resolved status. If both of these things are true, the blocked issue(s) are then transitioned into the "ready for dev" status.

This works well, and all involved are happy. Screenshot below.

The dev team has run into a case where a blocking issue is deleted instead of transitioned. They're asking for a rule to address this. I'm cobbling it together from the above rule that does work, but I'm hitting an error.

The Rule:

The Error

The following issues did not match the condition:

PGESDBX-21

JQL search failed for some issues. This is most likely because the JQL with smart-values was not valid for this query:

"(issue in linkedIssues("PGESDBX-21","blocks")) AND (project in (10173))" - Issue 'PGESDBX-21' could not be found in function 'linkedIssues'.

The newly-unblocked issue isn't being placed back into the "ready for dev" status, and I'm getting the above error that to my eye seems to be saying that it can't evaluate for issues related to the original because the original was deleted.

Putting aside the widely-held view that issues shouldn't actually ever be deleted, is there something I'm missing that would make this work?

[Bill Sheboy · Accepted solution]

Hi @Troy Parish 

I believe you have summed up the issue and a solution/work-around: the timing of the delete trigger firing is leading to the absence of information...preventing the rest of the rule from functioning as designed.

One work-around would be not to delete, or not delete immediately.  Instead use an "abandoned" flag (custom field) and transition issues to "Done".  That would indicate as "resolved/non-blocking" for your rule logic.  And adjusting any board filters to ignore "abandoned" issues would effectively make them vanish from views and reports.

If you still want to delete, use a scheduled trigger rule as cleanup to run once per day to delete abandoned issues.  With this strategy it may also help to tighten delete permissions such that only the scheduled trigger rule's user can do it...and so head off accidents.

Kind regards,
Bill

[Troy Parish]

Sorry for the lag, your reply was concise and great!

I'd hoped for a little more granular order of operations in how Jira saves records, but I understand the limitation now.

I'll run your workaround by the team, thanks again for a great reply!