Delete all Tempo worklogs from an issue using Jira Automation and Tempo's REST API

In this article I present a solution to delete all Tempo worklogs from an issue, using Jira Automation and Tempo's REST API. The reason for creating this article is because I've got a follow-up question on my previous article. So.. let's get this!

 

Requirements

Platform

Cloud

Application

Tempo Timesheets

Project Permissions

  • Browse Project
  • View all worklogs
  • Delete all worklogs

User profile

Project or Jira admin and above

Tempo REST API endpoints

Get worklogs from an issue

GET https://api.tempo.io/4/worklogs/issue/{issueId} 

Delete worklogs

DELETE https://api.tempo.io/4/worklogs/{id}

Rule description

This rule delete all Tempo's worklogs from an issue. Keep in mind that Tempo has a way of deleting all worklogs from a project, but this rule doesn't do this.

 

Prerequisites:

  • Create a Tempo API token

    • Go to Tempo>Settings,
    • Scroll down to Data Access
    • Select API integration

 

Rule

This rule has again pretty easy steps:

  • Manual trigger (or a trigger of your choice)

  • Send a web request to get all Tempo worklogs of the issue

  • Branch to run for every Tempo worklog using smart values

    • Delete a specific Tempo worklog

TempoRule001.png

 

Rule Breakdown

Now let’s break down the rule:

 

🔫 Trigger

For the trigger I went with manual rule, since I wanted to have complete control of when the rule will run. Of course fill free to adjust the trigger to be run only by a selected group. Since this rule was on my test instance in which I am the sole user, I left it blank:

worklogrule001 trigger.png

💡 Get all worklogs

The first component, after the trigger, is the “Send web request” component.

TempoRule002.png

As a web request URL we enter the following URL, based on the first REST API endpoint:

https://api.tempo.io/4/worklogs/issue/{{issue.id}}

Tempo's base API URL is currently https://api.tempo.io/4. So after the base url, we use the first endpoint, which is to get all Tempo's worklog /worklogs/issue/{id}. We replace {id} with the {{issue.id}} smart value so this rule can work on all issues to which we decide to run it. In addition we add as headers:

  • Content-Type ↔︎ Application/JSON

  • Authorization ↔︎ Bearer TEMPO_API_TOKEN

On authorization, you will enter as a value the word “Bearer” followed by the API token which we acquired from the “Prerequisites” section.

As the http method, we use “GET”, we leave the body as EMPTY and we make sure to check the “Delay execution of subsequent rule actions until we've received a response for this web request”. We can also validate the request if we click on the “Validate your web request” expand section and type an issue key.

 

✒️ Audit Log (optional)

I inserted a Log component just to make sure that I'm getting the correct worklogs IDs. To do that, I used the smart value

{{webResponse.body.results.tempoWorklogId}}

which yields the tempo worklogs IDs.

TempoRule003.png

🔀 Advanced Branching

The GET request from the previous web response will return a payload which we can further manipulate using the smart value {{webResponse}}. To be able to delete the worklogs it is imperative to know the worklogs ids. To do that we will use another smart value on the Advance Branching component:

{{webResponse.body.results.tempoWorklogId}}

TempoRule004.png

This advanced branching is different than the one from my previous article, since it's not imperative to split the values. We save the above smart value as tempoWorklogID (or a name of your preference).

 

❌ Delete each worklog

Next we add another “send web request” component.

TempoRule005.png

As a web request URL we enter the following URL, based on the second REST API endpoint:

https://api.tempo.io/4/worklogs/{{tempoWorklogID}}

We use the {{tempoWorklogID}} smart value which was constructed on the Advanced Branching component. Like before, we populate the headers accordingly:

  • Content-Type ↔︎ Application/JSON

  • Authorization ↔︎ Bearer TEMPO_API_TOKEN

As the http method, we use “DELETE”, we leave the body as EMPTY. You can again validate the request if you click on the “Validate your web request” expand section and type an issue key.

 

💰 A Penny For Your Thoughts

So that's it! That's the way to delete Tempo's worklog from an issue. Do you have any thoughts? Let me know if the comment section!

6 comments

Alex Ziegltrum April 27, 2023

Hey @Alex Koxaras _Relational_ 

I have to edit my previous post, because I had an error somewhere in my automation that I got corrected now. This example works just fine.

For me, I am combining the infos from you and from @Susanne Götz _Tempo_ here: 

Add worklog description and time spent as comment to the issue - Knowledge Base Articles - Confluence (atlassian.net)

which is helping me a lot! Both of your support is highly appreciated 😊

Thank you.

Cheers, Alex

Tim Heimes August 24, 2023

Hey,

 

This is great and could help me a big deal. I want to look deeper into your solution, since I am currently trying to achieve a similar thing. 

Do you think, it is also possible to MOVE worklogs for a certain period of time (like July 1st untill today) to a clone of the original issue?

 

Best regards,

Tim

Stuart Nealis March 20, 2024

Hi @Alex Koxaras _Relational_ - do you think this could be modified to only delete a portion of the worklogs associated to a specific Jira? We only want to retain the most recent 3 months, as we download and store the others elsewhere, and it would be ideal to be able to use automation to delete the older ones - both manually triggered at first and then maybe date triggered beyond that. Any ideas would be great, thanks!

Stuart

Julia Foden March 20, 2024

Hi @Stuart Nealis 

from my testing so far, this format works in the GET:

https://api.tempo.io/4/worklogs/issue/{{issue.id}}?from=2019-12-01&to={{now.minusMonths(1).endOfMonth.jiraDate.urlEncode}}
Like Tara likes this
Julia Foden March 21, 2024

You can also include a parameter 

&limit=5000

otherwise it defaults to 50 worklogs.

It works . . . . but not for approved timesheets. You get an error "The timesheet status must be open for the period". So for me unfortunately I don't think this can be part of the solution to https://community.atlassian.com/t5/Jira-Software-articles/Upcoming-changes-Introducing-per-issue-limits-for-list-fields-in/ba-p/2468177

Thanks @Alex Koxaras _Relational_ though, great article.

Like Tara likes this
Stuart Nealis March 21, 2024

@Julia Foden you are wonderful with providing this additional bit of script to get past the finish line! Unfortunately I'm receiving a "401 Unauthorized" error when I attempt to validate the web request, despite being granted site admin privileges, so I'll need to investigate further. 

Thanks again!

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events