Sum up all of subtask original estimate then put it to parent issue

feps October 23, 2024

Update:

Upon further investigation, I found that the steps I originally posted has incorrect value, and the correct value is timeestimate on step #3.

Here are the steps:

  1. Field Value Changed. Set Fields to monitor for changes to Time tracking then click next
  2. Add Issue fields condition, set Field to Status equals Subtask
  3. {{smart values}} condition, first value is {{fieldChange.field}} equals, second value is timeoriginalestimate → timeestimate
  4. Add a branch, set it to Parent
  5. Add an action, Edit issue and choose field Original Estimate then put this in the Original Estimate* 
    {{#=}} {{issue.subtasks.original estimate.sum}} / 3600 {{/}}

image.png


This also solved the problem I mentioned on bullet #2 in the answer section below. So now, even newly created Sub-task with original estimate field 0m then update it to any value will also successfully pass through. Original Estimate: 0m → 1h

I also want to add that, when you create a new Sub-task with initial Original Estimate: 0m then update it to any value. For example: 0m → 1h, there will be no action performed also. I do not know why changing from initial 0m → 1h is not counted as a change.

Here is the Audit Log that it is successful:

image.png

 

PS: So why do I even bother updating this when there are a lot of solutions out there?
The reasons are:

  1. I want to correct my mistake
  2. They are years old post and they have less visibility when searching, and some of the exact solution is hard to find and you need to scan through the comments
  3. I read that posting new question like this have more visibility :)

 

 


Original Post:


After spending 3 hours researching and tweaking automation rule. I wanna share this info to everyone. This post is likely not a question but a workaround solution to a common problem. Hoping this would help them save time and newbies like me in the future or my future self also ;).

My specific use case:

  • I want to trigger this rule only when subtask original estimate is changed.
  • Sum of all subtask original estimate then put it in the parent issue original estimate.
  • Jira Cloud version
  • Team-managed project

 



Here are the steps:

  1. Field Value Changed. Set Fields to monitor for changes to Time tracking then click next
  2. Add Issue fields condition, set Field to Status equals Subtask
  3. {{smart values}} condition, first value is {{fieldChange.field}} equals, second value is timeoriginalestimate
  4. Add a branch, set it to Parent
  5. Add an action, Edit issue and choose field Original Estimate then put this in the Original Estimate* 
    {{#=}} {{issue.subtasks.original estimate.sum}} / 3600 {{/}}

      Note:

  • there is a space between issue.subtasks.original [space] estimate.sum
  • If your project uses minute as the default time, then divide it by 60
    If hour, then divide it by 3600
    Since Jira calculates time using seconds.

image.png

For I don't know reason, Original Estimate is not available as the trigger in Field Value Changed. So I have to use a workaround solution, I use the Time Tracking field to monitor for changes. Then I set 2 conditions to match only Subtask issue type and Original Estimate is changed.

2 answers

1 vote
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 23, 2024

Hi @feps -- Welcome to the Atlassian Community!

This is a frequently asked scenario / question in the community, and there are lots of posts describing solution approaches.

Please note your rule only covers one of the possible cases.  The level of accuracy needed determines if other rules / paths through rules are needed.  These cases include, but are not limited to:

  • happy path: the Original Estimate field is updated for a Sub-task issue type
  • a Sub-task is created with an Original Estimate; this is an edge case due to the order of field updates for issue create and time tracking
  • a Sub-task is removed from a parent issue
  • a Sub-task is deleted
  • someone manually updates the Original Estimate field in an issue which has Sub-tasks
  • an external process alters a Sub-task in a way which does not generate a Jira event; this is another edge case, and can only be addressed by using a scheduled trigger rule to perform updates
  • etc.

 

Finally, smart values are name, spacing, and case-sensitive, with some additional curiosities for the time tracking ones (i.e., human-readable calendar / clock values versus number values).  When an incorrect smart value is used, that returns as null, leading to unexpected results.  To find the smart values, and custom field ids, supported for rules, please use this how-to article: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

 

Kind regards,
Bill

feps October 23, 2024

Hi @Bill Sheboy

Thank you for the thorough analysis.

Yes, I do keep in mind that this is a frequently asked scenario that's why I put my specific use case for this rule and saves you time from researching and tweaking rules on applying the sum of subtask original estimate to the parent issue.

The important note that I forgot to add are the possible cases/paths that you've mentioned in the bullet points and thank you for pointing that out.

And also, this rule needs improvement if you want to include all those possible cases you've mentioned above or will be needing to add more rule to compensate it all.

 


 

Bullet #1: happy path: the Original Estimate field is updated for a Sub-task issue type

The first bullet point is my intention for creating this rule. Create a parent issue. Add subtask issues and then update the parent Original Estimate field. Every time you update the subtask Original Estimate field, it will automatically sum up all the subtask Original Estimate field into the parent issue. But there is a problem here and it will be mentioned below.

 

Bullet #2: a Sub-task is created with an Original Estimate; this is an edge case due to the order of field updates for issue create and time tracking

This scenario is the problem on bullet #1, there will be no action performed when the subtask is created with an Original Estimate field.
Since I am not using this in my workflow, I am not sure about with this scenario but I guess it is not within the scope of the trigger when Field Value Changed?

I also want to add that, when you create a new Sub-task with initial Original Estimate: 0m then update it to any value.

For example: 0m → 1h, there will be no action performed also.
I do not know why changing from initial 0m → 1h is not counted as a change.

Just Jira things? just kidding.

But if you update from 1h → 2h, it will be counted as a change and the rule will pass through and automatically updating the parent Original Estimate: 0m → 2h.

I will try to update the rule above to include this problem.

 

Bullet #3: a Sub-task is removed from a parent issue

I did not include this in my workflow, so I will be manually editing the parent Original Estimate field if ever I removed a Sub-task from parent issue.
If you want to include this, you will be needing to improve the rule above I created or create a new rule for this one.

 

Bullet #4: a Sub-task is deleted

I also did not include this in my workflow, so I will be manually editing the parent Original Estimate field if ever I deleted a Sub-task.
If you want to include this, you will be needing to improve the rule above I created or create a new rule for this one.

 

Bullet #5: someone manually updates the Original Estimate field in an issue which has Sub-tasks

I also did not include this in my workflow, so I will be manually editing the parent Original Estimate field if ever I deleted a Sub-task.
Usually, I am the only one who updates the subtask issue which are assigned to me and I am not updating the parent issue Original Estimate.

 

Bullet #6: an external process alters a Sub-task in a way which does not generate a Jira event; this is another edge case, and can only be addressed by using a scheduled trigger rule to perform updates

I also did not include this in my workflow so this scenario is out of scope in the rule I created above.

 


 

And last one but not the least,

Finally, smart values are name, spacing, and case-sensitive, with some additional curiosities for the time tracking ones (i.e., human-readable calendar / clock values versus number values).  When an incorrect smart value is used, that returns as null, leading to unexpected results.  To find the smart values, and custom field ids, supported for rules, please use this how-to article: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Are you referring to this one?

{{#=}} {{issue.subtasks.original estimate.sum}} / 3600 {{/}}

This smart value came from an Atlassian team Sherry Goyal. The article posted on the community. And also, I already tested this one and currently working on my project automation rule.

Article Source: How-to-sum-up-logged-hours-using-automation-in-Jira-Cloud
Exact source for the smart value: original estimate smart values 

 

Here is the proof that it is working in the Audit Log:

image.png

 

--
Best regards,
Feps

0 votes
Temuri Memarnishvli
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
January 9, 2025

Hello, how can I add status filter on that? I mean if i want to sum up original estimates of the subtasks where status != Done?

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 9, 2025

Hi @Temuri Memarnishvli -- Welcome to the Atlassian Community!

Please try using smart value, list filtering with the math expression.  For example:

{{#=}}0{{#issue.subtasks}}{{#if(not(equals(status.name, "Done")))}}+{{timetracking.originalEstimateSeconds}}{{/}}{{/}}{{/}}

Kind regards,
Bill

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
TAGS
AUG Leaders

Atlassian Community Events