Delete all worklogs from an issue using Jira Automation with REST API

[#1]

In this article I present my solution to delete all worklogs from an issue, using Jira Automation and REST API (cloud).

Requirements

Platform	Cloud
Project Permissions	Browse Project, Delete all worklogs
User profile	Project or Jira admin and above
REST API endpoints	https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-worklogs/#api-rest-api-3-worklog-list-post (get all worklogs) https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-worklogs/#api-rest-api-3-issue-issueidorkey-worklog-id-delete (delete worklog)

Rule description

This rule delete all worklogs from an issue.

Prerequisites:

• Create an API token

• Encode the above token as Base64 to use it on your rule

To use an API token you must encode it as Base64. To quickly generate it go to this website (or similar) and enter yourmail@address.com:YOURAPITOKEN and hit encode. This will generate your authentication as base64 which will let you use it on your http request. Copy it and save it somewhere.

A full example of an http request can be read on this article by @Cristiano https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

Rule

This rules has some pretty easy steps:

• Manual trigger (or a trigger of your choice)

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

• Branch to run for every worklog using smart values

  • Delete a specific worklog

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:

Get all worklogs

⚠️ Before diving in to this module, it’s imperative to do all the steps described in the “Prerequisites” section. If you don’t know, please follow the links on that section or my instructions.

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

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

https://YOURDOMAIN.atlassian.net/rest/api/3/issue/{{issue.key}}/worklog

We use the {{issue.key}} smart value so this rule can work on all issue to which we decide to run it. In addition we add as headers:

• Content-Type ↔︎ Application/JSON

• Authorization ↔︎ Basic YOUR_BASE64_API_TOKEN

On the last bullet, we will enter as a value the word “Basic” followed by the encoded 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.

Advanced Branching

The above GET request will return a response which we can further manipulate using the smart value {{webResponse}}. To be able to delete the worklogs, and based on the second endpoint we will use, it is imperative to know the worklogs ids. So the previous step give us the proper information about the worklog ids. However the response we get has all sort of additional information, which is of no use to us.

So we have to find a way to get only the worklog ids. To do that we will use another smart value on the Advance Branching component:

{{webResponse.body.worklogs.id.split(", ")}}

The above mentioned smart value can be breakdown as:

• webResponse.body = we get the whole http response’s body

• webResponse.body.worklogs = we get all the worklog information

• webResponse.body.worklogs.ids = we get only the worklogs ids

• webResponse.body.worklogs.ids.split (“, “) = we split the values, creating in essence a list which we will use on the next step

We save the above smart value as worklogID (or a name of your preference)

Delete each worklog

Next we add another “send web request” component.

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

https://YOURDOMAIN.atlassian.net/rest/api/3/issue/{{issue.key}}/worklog/{{worklogID}}

Again we use the {{issue.key}} smart value so this rule can work on all issue to which we decide to run it. Like before, we populate the headers accordingly:

• Content-Type ↔︎ Application/JSON

• Authorization ↔︎ Basic YOUR_BASE64_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. Since we don’t want to get a response, you don’t have to check the “Delay Execution”. You can of course, but your rule will work if you leave it unchecked.

Results

The audit log upon running this rule will look something like the following:

We have the log ids (which we used as a component during the testing phase which I don’t describe in this article) and then the successful web request. It’s always good to cross check that your rule works properly!

Have any thoughts? Let me know if the comment section!

[Mark Jestings]

Thanx great article!

[Vikrant Yadav]

Thanks @Alex Koxaras _Relational_  for sharing very informative article. 

[Fabian Lim]

Excellent article @Alex Koxaras _Relational_ 

[Bill Sheboy]

Thanks, @Alex Koxaras _Relational_ 

I was following along with your answers to the other/question thread on this topic, and wondered about this approach also.  What concerns would you have about this rule causing a SLA/limits violation for automation (execution time/duration) and so causing the rule to fail?

Kind regards,
Bill

[Alex Koxaras _Relational_]

@Bill Sheboy hi!

Are you referring to these limits? If yes, then the only problem I would personally see with this rule is the Daily processing time. According to my tests, to delete 4 worklogs from an issue it takes about 4,5secs which is considerably high. But even if you create an app with forge and use the same endpoints it would take more likely the same amount of time (maybe a bit lower). But how many times would someone wants to delete worklogs and from how many issues?

[Bill Sheboy]

Thanks, Alex.  I recalled a limit on processing time and wondered about someone trying to run a cleanup on something with a long worklog thread...leading to lots of processing for the REST API calls.  Definitely an edge case...and probably should trigger a question: why exactly would one do that to an issue?  :^)

[Alex Koxaras _Relational_]

@Bill Sheboy one reason I can think of is because of a faulty automation rule which logs time :) 

Or if someone gave instructions to a team to log time on a wrong ticket. So you get a bunch of worklogs which are obsolete. But since the outcome of this article was triggered by a genuine question about how to achieve this, I would assume that people might actually have the need to delete all worklogs of an issue.

[Taranjeet Singh]

@Alex Koxaras _Relational_ Great article, and a great "Jira Automation" solution to one of the frequently encountered use cases!

[Sandra Carrillo]

Hi @Alex Koxaras _Relational_ , is it possible to delete all worklogs of a jira project?

We need to delete 16000 worklogs belong to 850 issues of the same project.

thanks for all.

[Alex Koxaras _Relational_]

Hi @Sandra Carrillo ,

I wouldn't recommend using jira automation for that number of worklogs and issues. You would hit the service limits quite fast.

Perhaps using a post function within a transition would be more appropriate. Or using a 3rd party app.

[Sandra Carrillo]

Hi @Alex Koxaras _Relational_ What post function or 3rd app would you recommend for that? Thanks a lot

[Benjamin Compayre]

Thanks @Alex Koxaras _Relational_ , however the outcome isn't working for me on our instance, see below :



I've triple checked everything in the rule and also tried to switch the API version to 2 for the delete action (same result as with version 3) : 

I've seen @Florian PEREZ got the same "405 Method not Allowed" on the other thread on the topic, any clue where it may come from? Everything I could find on the interwebz about it instructed me to switch to API v2, without luck as you can see above. Thanks in advance

[Alex Koxaras _Relational_]

@Benjamin Compayre what did you place on the smart branch?

[Benjamin Compayre]

@Alex Koxaras _Relational_  thanks for the quick answer, please find it below : 

[Alex Koxaras _Relational_]

@Benjamin Compayre do you have the delete all worklogs permission?

[Benjamin Compayre]

@Alex Koxaras _Relational_ yes indeed, via a project role (project admin), coming from my group membership as jira-administrator. Tried adding me directly there in the permission scheme, no luck

[Deleted user]

@Alex Koxaras _Relational_ @Benjamin Compayre 

first things first - thank you Alex for sharing your solution 😊 I used it as a template for deleting Tempo worklogs.

I am running into the same error as Benjamin. In my automation, I just want to delete a single Tempo worklog (the latest one) based on some pre-checks.

To my understanding, I can't use the approach using this API endpoints, right? Has anyone got this done this Tempo?

[Susan Wu]

You may want to check if the periods are closed in Tempo:

1. Check if period is closed for all in Period Management.

2. Check if Scheduler is active. 

If they are closed and/or active, you have to temporarily open and/or deactivate them before you can modify/delete Tempo worklogs in those periods.

BR,

Susan Wu

Tempo Product Expert

[Alex Ziegltrum]

Hey @Susan Wu 

thanks for picking up the topic :)

Our configuration looks like this:

This is deliberately, because we use our own 3rd party application, to get billable time from the worklogs to our ERP system.

Even with the configuration that way, I am able to modify even delete worklogs using the GUI, why shouldn't that be possible in an automation e.g. to prevent overbooking of original time?

[Alex Koxaras _Relational_]

@Benjamin Compayre  late response I know, and I apologize. I managed to replicate your issue ( @[deleted] this is of interest to you as well)

I noticed that on your rule you haven't checked the "Delay execution of subsequent rule actions until we've received a response for this web request" found on your "send web request" component. Once you check it and run your rule again, you will have no problem!

[Alex Ziegltrum]

Hey @Alex Koxaras _Relational_ 

thanks for picking it up again, very much appreciated. I could reproduce the automation rule as described here successfully, unfortunately it does not meet my requirements. Maybe you could help me on adapting it. In the end, my automation each Tempo worklog is checked and if criteria is met, this worklog must be deleted.

I have tested the exact rule of this example here. When it is triggered, it is excecuted succesfully w/o errors, I guess the Jira worklogs are deleted, but the Tempo worklogs are not deleted. They are still on the issue.

Is there a way to delete Tempo Worklogs? That would be fantastic!

Cheers, Alex

[Alex Koxaras _Relational_]

@Alex Ziegltrum I would assume that besides the rule you created and successfully deleted the jira worklogs, you have to create another rule using Tempo's cloud API.

• Create a tempo api token following these instructions.
• I would replace the first web request with this tempo request
• And then on the advanced branching I would send their delete worklog request.

Tempo's base path is https://api.tempo.io/4 

[Alex Ziegltrum]

Thank you @Alex Koxaras _Relational_ I will try and share my results.

[Alex Ziegltrum]

@Alex Koxaras _Relational_ 

I checked it out with this ( {{TempoToken}} = Bearer yxz123... but it gives same error with Basic yxz123...)

and I get this error response, when validating with an issue

Do I need to insert parameters in the web request body as "custom data" for the query?

[Alex Koxaras _Relational_]

@Alex Ziegltrum I've managed to create a rule for Tempo, which is slightly different in parts. I'll create a new article and comment here for you to see. However keep in mind that Tempo has an endpoint to (most likely) delete all worklogs from a project, but I didn't do that. I just did it for just an issue.