Automation for rolling up timetracking to Epic when moving tasks

[rob_jeal]

I have some automation that on an epic rolls up the estimates for the tasks/stories within the epic. The trigger for this is a value change in time tracking on the task, however I am trying to understand if I can easily add in an additional trigger which would be if a task is moved to an epic?

For example, I create a task and add an estimate but no epic (or the incorrect epic). I then assign the task to an epic but the Epic estimate roll up therefore isn't picking up that task's estimate (and likewise the epic I'm moving it from doesn't remove that task's estimate from it's own rolled up estimate).

Any ideas would be welcome! In previous places we used JMCF to achieve estimate roll up fields on epics but seeing if I can achieve it through automation in the first instance here without needing to get an add on for creating those custom fields.

[Bill Sheboy · Accepted solution]

Hi @rob_jeal 

Short answer: no, that is not fully possible with automation rules, although it can be worked around with additional rules

Longer answer:

For a scenario that sums a field from child issues to an epic, there are multiple conditions which could lead to a need to sum again...

• field value changes in a child issue
• new child issue is created and assigned to the epic
• existing child issue is newly assigned to an epic
• existing child issue is changed from one epic to another one
• existing child issue is deleted (or marked as abandoned)
• other automation rules do any of the above things
• tampering: someone manually alters the sum field in the epic
• Atlassian outage: refreshing the epic sum field when automation rules do not run, or do not run when expected
• etc.

Some of these could trigger the same event (and thus rule), but many do not.  The team must decide what level of accuracy do they want for the sum field, as that will determine the number of rules and their complexity.

Kind regards,
Bill

[rob_jeal]

Thanks Bill, that's really helpful

[rob_jeal]

@Bill Sheboy  I've added a couple of the rules needed just struggling with the moving between epics.. I added in a rule looking for "when the parent value changes". This works in terms of adding the estimate to the new epic, however it isn't obviously removing the estimate from the old epic (that the task is moving away from). Do you have any ideas how this would best be served please?

Thanks

[Bill Sheboy]

For a trigger on a field change, you may use the changelog fields to find the previous value: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--changelog--

And I just learned something new: after(?) the changes for the epic fields, the parent field does not work for the changelog.  Instead the Epic Link must be used to find the prior value.

After making the change to the new epic, you may add a branch on JQL to the previous epic, perhaps with this JQL, to then update the field value:

key={{#changelog.Epic link}}{{fromString}}{{/}} AND issueType=Epic

[rob_jeal]

Hi @Bill Sheboy , thank you for this. It is updating the previous epic estimate fields now but not correctly and wonder if it's my final "then" that is causing the issue? I've pasted the below, so the new parent is updating correctly but it appears the old epic is just getting 1 hour added to the estimate fields.. 

[Bill Sheboy]

To update the old epic, the lookup needs to be repeated for the old parent.

To make things easier to understand in the rule, try nesting the lookups consistently, like this:

• trigger: value changes for parent
• condition: issue type is one of Task, Story, Bug
• branch: to parent (This will be the current parent)
  • action: lookup issues to gather the siblings with the same parent
    • parent = {{issue.key}}
  • action: edit the issue (i.e., branched-to current epic) to update the fields
• branch: to the old epic with JQL
  • action: lookup issues to gather the siblings with the same parent
    • parent = {{issue.key}}
  • action: edit the issue (i.e., branched-to current epic) to update the fields

[rob_jeal]

Perfect, thanks @Bill Sheboy that's worked a treat! Appreciate all your help and explanation too, really helpful

[Bill Sheboy]

Awesome; I am glad to learn that helped!

[rob_jeal]

Hi @Bill Sheboy , hoping you might be able to help with the latest issue I've ran into with this.. What we discussed previously worked in terms of updating original & remaining estimate fields correctly, I just wonder if it's possible to also update the "time spent"?

It doesn't present itself as a field on the "edit issue fields" action and wondering if it is possible?

E.g. if I've logged 7.5h to a task under an epic, when I move that task it updates the new epic to add the 7.5h to the epics time spent, and removes it from the old epic?

Thanks for your help, I think this is the last scenario now I've not yet covered.

[Bill Sheboy]

That will be more difficult once the time is logged versus just changing remaining or original estimates.  Disclaimer: I have never tried this with an automation rule.

As you can see from these manual update instructions, worklog changes require an edit (or delete) of the specific work log: https://support.atlassian.com/jira-software-cloud/docs/log-time-on-an-issue/

If you can correctly identify the specific worklogs, the rule could call the REST API functions to update them using the Send Web Request action.  That would probably require this:

• get the worklogs for the issue
• identify the correct worklog id values for changes
• update or delete those worklogs

Here are a couple of references if you want to try this:

https://community.atlassian.com/t5/Jira-Software-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-worklogs/#api-group-issue-worklogs

[rob_jeal]

Hey @Bill Sheboy  - sorry to resurrect this chain... I just wondered if you may have any thoughts on an issue we've experienced with the roll up automation (for time logging).

A user will log their time to a task and the timelogs then roll up to the Epic as expected, this works great. The issue we have is that the time logged against the epic shows the User that logged the time as "Automation for Jira" as opposed to the original user who logged the time.

In most cases this would be fine but we have this integrated with another system which pulls in time logged by users and matches to users in our other system, so as it can't find "automation for jira" it's causing errors with the integration.

Wondered if there is anyway for the roll up automation to still present the user logging the time as the original user and not "automation for Jira" on the epic? 

Thanks any thoughts would be great.. 

[Bill Sheboy]

It is not possible to log work on behalf of another user, as the REST API does not support that. 

Here is a suggestion from over 10 years ago and the last Atlassian updates are from 2015 so little progress noted: https://jira.atlassian.com/browse/JRACLOUD-30197  I also looked in the developer community for this need and only found ideas like "build your own app which impersonates the other users..."

For your scenario, how about this work-around:

• when you copy the log to add it to the Epic, add the user from the worklog in the description of the Log Work action
• in your external system that pulls the time logged, when the user is "Automation for Jira", extract the actual user from the description field

[rob_jeal]

Thanks Bill, appreciate that suggestion that could work thank you!