Automation whenever subtasks and linked tasks are changed

[Anne Dietz]

I am using an automation to calculate the number of subtasks and linked tasks on a story that is then displaying as the story points (we're not at a stage where we want to really determine the story points ourselves). The formula I have is {{issue.subtasks.size}} + {{issue.issuelinks.inwardIssue.size}} + {{issue.issuelinks.outwardIssue.size}}. I have it setup so that it runs extremely well when subtasks are created and when linked tasks are added, but I was wondering if there was a way to simplify it so that it would run the automation whenever subtasks and linked tasks are added, moved, deleted, etc. so that we don't have to have separate automations for each one. Anyone know if this is possible?

[Bill Sheboy]

Hi @Anne Dietz -- Welcome to the Atlassian Community!

I wonder if you could change to just use the issue updated trigger and update your count unconditionally.  This would cause a few unnecessary updates due to changes from unrelated fields (e.g. description comments, etc.).  You might mitigate that by using the changelog and conditions (based on issue type) to see if subtasks or links were impacted, and only proceed if they were.

Kind regards,
Bill

[Anne Dietz]

Hi @Bill Sheboy!

Thanks so much! It looks like that would work for subtasks on the story but not for linked issues. I think I would just need a separate one for deleted or removed linked issues. I have one setup for removed linked issues, but I don't know yet if the linked issue is deleted instead of removed if that will trigger it.

[Bill Sheboy]

We are not using delete, so you would need to try that to see if the change to the links triggers the rule. 

We disabled delete and instead use a custom field, Abandoned.  There is no "undo" with Jira Cloud, so it saves a lot of "oops" situations.

[Anne Dietz]

Thanks, Bill! That is very helpful to hear how others are doing it. I'm not too excited about the team having use of the delete function, but we've been relatively small until now so it hasn't caused really any issues yet, but I'm sure we'll reach that point when it does.

[Bill Sheboy]

Thanks, Anne.  Just to follow-up, when you try the delete issue, does it detect that as changing the links in the trigger for any linked issues?

[Anne Dietz]

That's a great point for testing. Right now when I'm testing, I'm not deleting anything that has linked issues underneath, but it is possible that they might down the road. I'm testing the delete on the Story subtasks, but I've also grouped it with Issue Moved and Issue Updated. It looks like this:

The issue with this is that it is seeing the new parent and not the old parent for moved issues. Ideally, I'd like it to see both. I've tried For Linked Issues instead of Parent and For Destination Issue, but my triggers aren't right for it. I was contemplating if I could run it up to the epic level and have it flow down, but I need the epic to be the sum of all the tasks in all the stories underneath it, so I don't think that would work out either.

[Bill Sheboy]

Regarding move, I recall seeing some open issues on moves correctly providing the "from" for automation.

How about this: split the problem so you have one rule which roles up subtasks to the story, and a second one for stories to epics?  Having two rules reduces the complexity, simplifies the testing, and will generally be more maintainable.

One key to making this work is when a change to a story could trigger the epic rule, look in the rule details to enable the option "Allow rule trigger".  This is disabled by default to prevent accidental looping conditions.