Reduce Original Estimate for Unplanned work task when a Spike task is created

[Eydie Fitzgerald]

Hello,  I'm trying to create automation that when a Spike task is created in an open sprint, then look up tasks with summary Unplanned work in open sprint, Subtract the Original estimate of the spike from the Original estimate of the Unplanned work..

I've created the following, which will only subtract time from the spike, not the unplanned work task.

1. When: Work item is created
2. Issue type equals Spike
3. Then: lookup work items using JQL Issuetype = 'Task' AND summary ~ 'Unplanned work' AND sprint in openSprints()
(I have tried this before the branch and within the branch.)
4. Branch: For: current work item
5. Then: Edit work item fields original Estimate
 Using:  {{lookupIssues.timeoriginalestimate.minus(triggerIssue.timeoriginalestimate)}}

Now, this works, but it reduces the time from the newly created Spike task and NOT from the Unplanned work task.  I am hoping that someone can help me figure this one out.  What am I missing?

[Bill Sheboy · Accepted solution]

Hi @Eydie Fitzgerald -- Welcome to the Atlassian Community!

Without seeing your rule and audit log details...

From what you describe, the rule is branching to the current work item...which would be the trigger one for what you show.  The rule would instead need to branch to the "Unplanned work" one using a branch on JQL to access it for the edit action.

Also, when using the Work Item Created trigger, there can be timing problems...potentially causing rule errors and unexpected behaviors.  I recommend always adding the Re-fetch Work Item Data action immediately after that trigger.  This will slow the rule slightly, reloading the data before the steps proceed.

If that does not help, please post images of your complete rule and audit log details for context.  Thanks!

Kind regards,
Bill

[Eydie Fitzgerald]

Thank you SO MUCH for the advice of a delay.  I added a 15 second delay before the branch where I performed the JQL search of unplanned work and it's working beautifully!

[Bill Sheboy]

Awesome; I am glad to learn it is working!  Please consider marking this question as "answered" to help others with a similar need find solutions faster.  Thanks!

And also...please note the Delay() action does not reload data; it just waits.  Adding a re-fetch action instead will reload the data.  This helps because the root cause is the rule can start before all of the data is ready for use with the Work Item Created trigger.  This is another good reason to not add conditions to triggers yet, but instead use separate conditions after the re-fetch.  For example:

• trigger: work item created (with no conditions)
• action: re-fetch work item data
• condition: issue type equals Spike
• ...

Atlassian knows about this defect and is working on architectural changes to resolve it, but there is no announced timeframe yet.

[Eydie Fitzgerald]

Thank you.  I had never used Re-fetch work item data.  Here is what I have so far, however, the automation wants to update any tasks that match my JQL and not just MY tasks or anyone else who creates a task.
We would use Creator, but often times someone else may create a Spike and assign it to another user.

Trigger:  When: Work item created

Then: Re-fetch work item data

Issue type equals Spike

Branch For:  Current work item

PLEASE NOTE:  I have tried using both issue.assgnee.displayName as well as leaving that off all together.  Adding it, gives an error and nothing happens.  Leaving it off edit's all that match IF: Work item matches JQL - I've tried many things.  It seems to do all tasks or no tasks.

[Bill Sheboy]

I do not believe you want to use Branch -- For Current Work Item.

You described updating a different one, the Task for the unplanned work.  And so the rule would use JQL to branch to that work item to perform the edit.

[Eydie Fitzgerald]

Here is what I have now. 

If I click on the branch JQL, Validate, It finds my task.  But when I create a new Spike, the rule runs "Success" - No related work items could be found. 

Before adding AND assignee=currentUser() it was updating all tasks with the same summary (To be expected). 

This one is really depleting my brain cells.
note that the summary of what I'm looking for has a strange name so that I can test and only update the two test tasks I have with that name.

[Bill Sheboy]

Thank you for those images, @Eydie Fitzgerald 

In the branch on JQL, is this option selected below the JQL:

Only include work items that have changed since the last time this rule executed

If so, that is the problem why the rule cannot consistently find it.  Please deselect that option and re-test.

[Eydie Fitzgerald]

Thank you for that suggestion.  But it is off.

[Eydie Fitzgerald]

What is boggling my brain more than anything, If I don't have assignee=currentUser() it updates all matching tasks, again that's to be expected.

When I validate the JQL - it finds the two test tasks

When I validate the IF assignee=currentUser()- it finds MY task.

The audit log says "success" but in the JQL Branch, 

• The work item didn't match the specified JQL.
• The chosen rule actor doesn't have permissions (or work item security level permissions) to view the work item.  (The actor is the Automation for Jira - global admin)
• the work item was deleted or wasn't indexed by Jira yet (in rare circumstances)

We recommend using the 'Issue fields condition' for more consistent results.

[Bill Sheboy]

Thanks for your diagnostic checks as the rule actor was my next suggestion :^)

When the rule runs with that JQL, currentUser() would probably try to use Automation for Jira, and that does not match your scenario.  Let's use the initiator in the JQL as that is the person who created the work item:

AND assignee = {{initiator.accountId}}

[Eydie Fitzgerald]

That did it!  You're a genius!  I'm so thankful for your advice.  I searched everywhere to find that piece.  I tried so many variations.  I was avoidant of using initiator for fear that it would trigger for someone who created a spike task on someone's behalf