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:
Increasing the worklog limit to 10,000 worklogs per issue against the previously suggested 5,000 worklogs per issue.
Extending the timeline to enforce these limits to December 2024.
Two new API solutions - Bulk Move and Bulk Delete to use for worklog issues breaching that 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.
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.
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:
Easily keep issue worklogs under the 10,000 limit so you can continue logging worklogs on the same issue.
Prevent data loss by transferring worklogs to another issue instead of deleting them.
Save time and eliminate repetitive work by moving or deleting worklogs in bulk.
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 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.
Some limitations exist with these APIs currently, and efforts will be made to address them in the future iterations.
Up to 5,000 worklogs can be deleted at a time.
Limited to one issue: i.e., you can delete worklogs from only one issue at a time.
No notifications will be sent for deleted worklogs.
No ability to restore: i.e., once a worklog is deleted, it is permanently deleted from your database. It can’t be restored.
Up to 5,000 worklogs can be moved at a time.
Limited to one issue: i.e., you can move worklogs from only one issue at a time.
Worklogs containing an attachment can’t be moved.
No issue history will be recorded for moved worklogs.
Time tracking will not be updated for the source and destination issues.
No notifications will be sent for moved worklogs.
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.
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.
If you’re using Tempo, please refer to Tempo solutions for Worklog limits for their solutions around worklog limits.
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!
Apoorv Aggarwal
2 comments