Jira: Delete all worklogs using Jira Automation and REST API

In this article we will see how to delete all worklogs from an issue, using Jira Automation and REST API (cloud).

Rule description

This rule delete all worklogs from an issue and 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. Read the full article for more information.

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.

Read the complete article

at the Atlassian Community!