Increase custom field number value (billed) in an advanced branch from a tempo worklog web request

[André]

As an example I have 5 Tempo worklogs on an issue, 3 are billable and 2 are not billable.

Each time a log is entered the following automation is triggered:

I order to better understand the issue I've added a comment for each billable worklog:

The custom field has at the end the last iteration value, instead of the needed sum of 6h.

I've tried to get this running with updating the issue field (triggerIssue as well as issue) and getting the value again via web request in order to increase it. I've tried the same now via a project property. But in none of the cases the value is updated withing the loop. It always remains within the loop with the original value that it had outside the loop.

How can I get an increasing number field that modifies the outer issue custom field (JQL not possible with TEMPO)

[André · Accepted solution]

@Bill Sheboy I've seen many great posts from you, maybe that's an easy answer for you? Thanks.

@Simmo Do you have any ideas? - thanks

[Bill Sheboy]

Hi @André -- Welcome to the Atlassian Community!

Without seeing your entire rule, or understanding the problem you are trying to solve (i.e., why do this), I note three things in what you show:

• The rule makes edits to the issue, one after another
  • When an edit occurs, it uses the issue state at the time the rule triggered, regardless of any edits that happen during the rule.
  • When you want the prior edits to be accounted for in the rule, add a Re-fetch Issue action after the edit and before the updates need to be "seen".  However...
• The rule has a branch over multiple things
  • Branches which could process more-than-one-thing run in parallel and asynchronously.  There is no guarantee of when such branches will complete, up until the last step of the rule.
  • And so the actions within the rule are not additive, and...
  • The branch is likely still running if there are rule actions after the branch.
• The logic inside the branch seems to repeatedly call the REST API with the Send Web Request action
  • I expect this rule to be both slow and possibly non-deterministic in behavior as a result

Putting those things together, it is likely the rule is walking over prior issue updates.  This could be confirmed if you view the issue history to observe the repeated edits.

Kind regards,
Bill

[André]

@Bill Sheboy thanks a lot for the quick answer.

What do you mean with "add a Re-fetch Issue action after the edit"?

Mainly I'm searching for a possibility to have an increasing variable within a advanced loop, that I can use once to update one sum filed. As I didn't find any possibility I tried these variants.

We need one sum off all billable worklog items within an issue. Therfore we need to check all worklogs of one issue if they are maked billable and the take their sum.

At the end we're not interested of the sum of remaining time, but in the sum of remaining billable hours.

[Bill Sheboy]

Thanks for that additional information.

For an example of what I meant by the Re-fetch Issue actions...

1. trigger: some trigger with an issue
2. action: edit issue for some field
3. action: edit issue for another field

In this example, the edit in step #3 is based on the issue and data conditions at the trigger timeframe, and not from the step #2 immediately prior.

1. trigger: some trigger with an issue
2. action: edit issue for some field
3. action: Re-fetch Issue
4. action: edit issue for another field

Back to your original scenario, you are gathering the Tempo worklogs for a specific issue and then trying to sum the billable time.

Reviewing this endpoint, isn't the billableSeconds value available when the worklogs are queried? https://apidocs.tempo.io/#tag/Worklogs/operation/getWorklogs  I am not using Tempo currently so please confirm this for your site.

If so, you could sum the data using smart value, list filtering on the results in one step after that first Send Web Request call by filtering for the ones where billableSeconds is greater than 0.  That would eliminate the need for the branching to lookup each log entry.

[André]

@Bill Sheboy unfortunately not. The billableSeconds are only to be added to the sum, if the attribute (within another array) with the key "_Billable_" contains the value "Billable".

But I manage to get now all in a very complex smart value operation.

Still my questions reamain:

1. Is there any possibility to have any running variable in a loop, that can be used even after the loop.

2. Is there a possibility to stop a running loop when a check fails

[Bill Sheboy]

For your specific questions:

1. Is there any possibility to have any running variable in a loop, that can be used even after the loop.

Answer: Not with automation rules currently.

As such rule branches run in parallel and asynchronously, they apparently do not share any storage that could be used for such a variable.  Using something outside of the issue (like a project property) is unlikely to work due to update collisions.  And, because the branch may not complete before the steps after it start, such a value could not be relied upon.

There is an open suggestion to add an option for serial vs parallel, rule processing, which you may watch or vote for to see progress: https://jira.atlassian.com/browse/AUTO-32

I have seen brittle workarounds using multiple rules, but they rely on forecasting rule duration and assuming no automation outages  / slow downs before completion.  For example:

• create one scheduled rule that performs some activities
• create a second scheduled rule that runs at some point when it is expected the first rule has completed, and then complete the dependent activities

2. Is there a possibility to stop a running loop when a check fails

Answer: No.  Please see answer to the first question.

[André]

@Bill Sheboy thanks again for your very quick replies.

A real pity. I've now also voted for the suggestion to get a massive improvement.