Hi everyone,
We are using Jira Cloud along with Tempo Timesheets for our time tracking. For metrics and reporting purposes, we need the time logged on Bugs to also be reflected/added to their respective Parent issues.
To achieve this, we configured the following automation rule:
This workflow works perfectly when a worklog is Created. However, we run into major data duplication issues when a worklog is Updated or Deleted.
For example:
1- A developer logs 2h on a Bug. The automation correctly logs 2h on the Parent.
2- The developer later updates that same worklog from 2h to 1h 45m using Tempo.
3- The automation triggers again under "All worklog operations", takes the new value (1h 45m), and adds it to the Parent. Now the Parent has a total of 3h 45m logged instead of just updating to 1h 45m.
We have the trigger in all worklog operations, maybe made another automation flow with the Updated trigger?
Anyone has run into a similar problem or has any insights regarding mine? Thanks in advance!
Regards,
Asier
First thing, I am just another customer making a suggestion, and I am not an Atlassian or marketplace vendor employee. With that out of the way...
Your rule is triggered on a change to a field (i.e., time tracking) and you describe using "different epics for each month with different sprints."
There are several ways the total time tracking value across the children could change beyond the field change and the apparent re-assignment of children to new parents every sprint or month. For example, work item deletion, work item move to a new space, work item type change, etc. Depending upon when and how accurately you want to track the summed values, consider using:
To learn more about using multiple rules for sum / synch scenarios with parent and child work items, please see this article I wrote on the topic:
Kind regards,
Bill
Hi @Asier Vadillo,
The duplication comes from the rule adding the worklog value to the parent on every operation. On an update or delete there is no clean amount to subtract, so each event piles on top of the previous total.
The reliable fix is to stop incrementally adding and instead recalculate the parent total from scratch and overwrite it on every worklog operation. That way create, update, and delete all converge on the correct number.
A rule along these lines:
parent = {{issue.parent.key}}).{{lookupIssues.timespent.sum}}.Because step 3 overwrites the field with a freshly computed total rather than adding a delta, an edited worklog of 2h to 1h 45m, or a deletion, is reflected correctly the next time the rule runs.
One caveat: keep the rollup in a dedicated custom field rather than the parent's own Time Spent, since the latter is derived from actual worklogs and can't be safely overwritten.
Hope this helps, Paul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Following up on the recalculate-and-overwrite automation idea, @Asier Vadillo: if the goal is mainly reporting (seeing each parent's total logged time, including its children), there's a route that sidesteps the sync problem entirely, since there's no automation to keep in step and nothing to double-count.
If you're open to an app from the Atlassian Marketplace, JXL for Jira is a spreadsheet/table view for Jira that rolls Time Spent up the hierarchy automatically. You view your issues as a parent/child tree and add a sum-up on the Time Spent column, so each parent shows the total logged across its children. When a worklog is added, edited, or deleted, the total just reflects the current values, with no rule to maintain.

It won't write the total back into a Jira field, so if you specifically need that value stored on the parent, the automation approach is still the way. But for a live, always-accurate view it's a lot less to maintain.
Disclosure: I'm on the JXL team.
All the best, Paul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Paul Glantschnig _Appfire_ ! Thanks for the answer!
We have a problem here, we use different epics for each month with different sprints. But a bug can be moved from one to another (For example a bug in May, is not finished so we move it to June).
If I follow your approach with the time spent sum of the child issues, the work logged in May would also count for the time in June.
Thanks again!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see, you're right, that won't work in this case. Thanks for clarifying.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.