In this article I present my solution to delete all worklogs from an issue, using Jira Automation and REST API (cloud).
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) |
This rule delete all worklogs from an issue.
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
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
Now let’s break down the rule:
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:
⚠️ 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.
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)
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.
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!
Alex Koxaras _Relational_
Atlassian Solution Architect
Relational
Athens, Greece
1,347 accepted answers
36 comments