Introducing Bulk Move and Bulk Delete Worklog APIs

[#1]

This post serves as a continuation to our previous update where we introduced issue limits for Jira cloud to improve performance and reliability. We rolled out the issue limits for comments, attachments, linked issues and remote links.

In response to your feedback, we paused the roll-out of worklog limits to build relevant solutions prior to enforcing these worklog limits.

This post shares three new communications to worklogs:

1. Increasing the worklog limit to 10,000 worklogs per issue against the previously suggested 5,000 worklogs per issue.

2. Extending the timeline to enforce these limits to December 2024.

3. Two new API solutions - Bulk Move and Bulk Delete to use for worklog issues breaching that limit.

---

New worklog limit

We have taken into account your feedback on the proposed limit of 5,000 worklogs per issue. In response, we are increasing this limit to 10,000 worklogs per issue. This modification enables you to incorporate and preserve twice the number of worklogs compared to the initial suggestion.

---

Updated timeline for enforcement of worklog limits

While limits for all other issue entities were implemented according to the initial schedules, we previously delayed enforcing worklog limits until July 2024. Now, to allow you ample time to utilize the new Bulk Delete and Bulk Move APIs (see below), we have further extended this timeline to December 2nd, 2024. Within this phase, we suggest using the APIs to delete or move worklogs from issues with more than 10,000 worklogs.

If you utilize Timesheets by Tempo to log worklogs, we recommend consulting their solutions, which are shared in the 3P app section below. 

---

New worklog

The new Bulk Delete and Bulk Move APIs are accessible for use across all Jira and JSM plans - from Free to Enterprise. With these 2 APIs, you can:

1. Easily keep issue worklogs under the 10,000 limit so you can continue logging worklogs on the same issue.

2. Prevent data loss by transferring worklogs to another issue instead of deleting them.

3. Save time and eliminate repetitive work by moving or deleting worklogs in bulk.

Bulk delete API

The Bulk Delete API simplifies the process of deleting multiple worklogs associated with a specific issue. For example, if there are 12,000 worklogs on Issue-1, you can efficiently delete up to 5,000 worklogs to stay within or below the set limit. This action reduces the worklogs on Issue-1 to 7,000, allowing you to seamlessly add additional worklogs as needed. Time tracking on the Issue-1 will be updated accordingly.

This API allows for the deletion of up to 5,000 worklogs in a single operation.

How to implement: Fetch the worklog IDs you plan to delete using the Get Issue Worklogs API. Then use the Bulk Delete API to delete them.

Follow this runbook - Runbook-bulk-delete-worklogs for further assistance. 

Bulk Move API

Bulk move API will allow you to move the worklogs from one issue to another. For instance, if you have 12000 worklogs on Issue-1 and you still want to log more worlogs on the same Issue. You can move upto 5000 worklogs to another Issue-2. This would allow you to continue adding more worklogs to the same issue once the worklog limits are imposed.

This API allows for the moving of up to 5,000 worklogs in a single operation.

How to implement: Fetch the worklog IDs you plan to move using the Get Issue Worklogs API. Then use the Bulk Move API to move them.

Follow this runbook - Runbook-bulk-move-worklogs for further assistance. 

---

API limitations

Some limitations exist with these APIs currently, and efforts will be made to address them in the future iterations.

Bulk Delete API

1. Up to 5,000 worklogs can be deleted at a time.

2. Limited to one issue: i.e., you can delete worklogs from only one issue at a time.

3. No notifications will be sent for deleted worklogs.

4. No ability to restore: i.e., once a worklog is deleted, it is permanently deleted from your database. It can’t be restored.

Bulk Move API

1. Up to 5,000 worklogs can be moved at a time.

2. Limited to one issue: i.e., you can move worklogs from only one issue at a time.

3. Worklogs containing an attachment can’t be moved.

4. No issue history will be recorded for moved worklogs.

5. Time tracking will not be updated for the source and destination issues.

6. No notifications will be sent for moved worklogs.

---

What happens when an Issue reaches the limit

Once a limit has been reached, you won’t be able to add more of that type of data to the issue. For example, once you’ve added 10,000 worklogs on an issue, you won’t be able to add more worklogs on the same issue. Users will receive an error to inform them that they have reached the limit. This would happen once the limits are enforced.

This won’t affect existing data for issues that are currently over the limit. But enforcement of limits will still apply for any new issue data being created on existing issues.

---

Impact to migrating issues that are over the limit

Migrations assessments will flag issues that are over the limit. However, only once the limits are enforced, it would start applying to new entities after migration, as mentioned in the previous section.

---

So you're using a 3P app to log worklogs

If you’re using Tempo, please refer to Tempo solutions for Worklog limits for their solutions around worklog limits.

---

What next!

We’d recommend you to start using the APIs above to bring the issues below the 10,000 worklog limits. Furthermore, use the comment section to provide your feedback and queries. We are eager to learn how we can improve the overall experience for you.

We appreciate your cooperation and backing as we strive to deliver enhanced and dependable experiences on Jira!

[Rich Scire]

What happens when someone tries to create the 5,001st worklog? Does the create fail?

[Apoorv Aggarwal]

Hi @Rich Scire

An issue can have upto 10,000 worklogs. We previously suggested 5,000 but have increased it to 10,000 worklogs per issue. 

After 2nd December, when the worklog limits are enforced, creating more than 10,000 worklogs would be restricted. If someone wishes to continue adding worklogs to the same issue, they can use one of the solutions mentioned above. 

[Tuarn McInerney]

How are you meant to report and view which issues are nearing this worklog limit? What auditing tools have you put into place to ensure we can maintain our issue integrity and prevent failure to log work.

Before the original 5000 log limit was enforced, I was notified that we would have a tool/report to do this via Atlassian support, but I am surprised the capability is not outlined here.

[Scottie Brimmer]

So this is worklogs, and not hours, correct?

If a user logs 8h/day to JIRA-1234 for 5 days, that's 5 worklogs?

OH!  Is there an automation to create a new issue (clone) once the 10,000 worklog limit is reached?

[Apoorv Aggarwal]

@Tuarn McInerney here's the API that you can use to find Issue IDs that are nearing the limit or over the limit Get Issue Limit Report API. 

[Christopher Kraft]

Are the limits only for one issue or above the issue hierachie?

So if you have an epic with 9.999 entries and one child task with 2 entries. Is this fine?

[Apoorv Aggarwal]

@Scottie Brimmer Yes, these are worklogs and not hours. Correct, if a user logs 8h/day for 5 days, that's 5 worklogs. 

You can use the API Get Issue Limit Report API as a trigger and issue cloning as an action. 

[Jason Mansfield]

Hi

I've tried using the Bulk Move Worklogs script from the runbook Runbook: Bulk move worklogs in Jira Cloud | Jira | Atlassian Documentation, but it's returned some strange results.

Using the full script I have run this in Python to test moving worklogs between issues, but whilst the script execution returns the status that it was successful, I am seeing mixed results of this within our Tempo App for our site that we have.

The Tempo app's view of those timelogs doesn't show any change of the worklog (ie it's still with the source and hasn't moved to the destination).
However, if I use the GET API call rest/api/3/issue/{issuekey}/worklog and check this for the source and destination issues, I can see the worklog has moved.

Just to check, there isn't some sort of time lag between Tempo and the REST call?

[Rich Scire]

Hi, Can someone provide a screenshot of the error message displayed when a user tries to add a worklog to an issue with more that 10,000?

Thanks!