Tempo’s Solutions for Atlassian’s 10K Worklog Limit

[Susan Wu]

We would like to update and reply to some of the questions and feedback in the comments.

All the features below are live following Atlassian's 10K worklog limit.

You can run Tempo Reports to show worklog counts to track issues exceeding the 10k limit. 

For those who don't need to keep the original issues, you can just create new issues and manage the worklogs of the old issues later with bulk worklog editor.

To move old worklogs, you need to enable Override modes to bypass closed periods/approved timesheets with bulk worklogs editor. 

At the moment, bulk worklogs editor should be working smoothly. Please give the system some time to process. If it's not improved after 15-30 minutes, please open a support ticket.

To keep the original issues, you need to move all old worklogs, except the ones done by inactive/deleted users.

Also, you can temporarily allow logging time on archived/closed accounts to move worklogs of account linked issues. 

If you have enable the option for aggregating internal issues, you will see normal individual worklogs in Tempo reports and you should see 1 worklog per day in Jira. 

Please contact Tempo Support if you have any other questions. 

Best regards,
Susan Wu
Tempo Product Expert

[Shawn Stevens]

For the Aggregate internal issues. 

I'm still not sure how or where I would see the aggregation. See the screenshot below. 

 
I'm just trying to understand how i can tell if the Aggregate for Internal issues is actually working. When I do the Report in Tempo it shows >500 entries already and I see the individual users. 

Also based on your below information I still need to address the quick fix I did. Created a new ticket and closed the old ticket to get folks back working again. I would still need to go through and move some of the logs from the original ticket to a different ticket. Basically splitting my one internal ticket into 3 individual tickets to hold the >22K worklog entries??

[Susan Wu]

Hi @Shawn Stevens ,

You need to have view all worklog permission to see others' worklogs in the Activity > Worklog tab. Please be aware that the Worklog tab is showing Tempo worklogs when Tempo is set as Time Tracking Provider.

To see Jira worklogs, you can only view the hours aggregated in the Activity > History tab, which every entry is performed by Tempo Timesheet.

Yes, you still need to clean up all the issues exceeding 10k worklogs.  The new issues is mainly for others to be able to continue log time. Since the aggregation is enabled for internal issues, you can move all 22K worklogs into the same new issue without create more internal issues. The old issue will have the worklogs of the inactive and deleted users.

[Paul Howard]

@Susan Wu - your response to @Shawn Stevens isn't providing me with the clarity I seek to validate our aggregation setting is in effect. Here is a partial view of all the 'History' of a brand new ticket opened 4 days ago, with no worklogs/time being moved over. There are about 50 individuals reporting time against this issue.

[Shawn Stevens]

I am also with @Paul Howard the information is not apparent that the Aggregation is working. If the entries in the history said something like "aggregated" because right now looking at Paul's screenshot, I can't tell either and that looks like mine. I am in the same situation, created a new ticket, and everyone started logging time there. 

Considering that I created a new ticket and shifted everyone over to use the new ticket, I shouldn't need to clean up the old ticket that had 22K on them. Or are you saying because i have aggregration on now for the new ticket that when I move the 22k it will consolidate that down to say 365 days of logs. 

[Susan Wu]

Hi @Shawn Stevens and @Paul Howard ,

To confirm the number of Jira worklogs generated for an internal issue, you can run Jira REST API - https://{company name}.atlassian.net/rest/api/3/issue/{issue key} to get the actual numbers of Jira worklogs, which should be 1 worklog per day. If you have created the new internal issue on Monday and logged at least 1 worklog per day, you should have 4 Jira worklogs.

When you move 22k worklogs to the new internal issues, it will generate the same number of worklogs as the days since your issue's creation date.

If your issue was created on 2024-01-01 and users have logged time on it every single day including holidays and weekends until today, then you should have 346 worklogs instead of 22k. If there are any days that no one has logged time, then you will have less than 346 worklogs. 

[AB]

We are facing the same issue as others. Most of the users are no longer in the company.

I see this error when I tried to move worklogs using Tempo Bulk Edit, "User does not have permissions to log work on the destination project." 

Since we can't fix this, I used Jira’s Bulk Worklog APIs to move worklogs. Now we are under 10k worklog limits, yet Tempo still errors out when logging. 


Does it need any sync period for Tempo to know that worklogs on Jira are now under 10k? 

[Muhammad Majeed]

Overall, we managed to move all the worklogs to newly created archive tickets and deleted all non-movable worklogs, which  Unfortunately, we had no other choice. Support so far has been a lot of pointless chatter and shifting responsibilities for this or that problem back and forth between Jira and Tempo.

[Karin Kennergren]

I am at a loss for what to do. Can someone advise me? We got hit by this at a time where no one has expert knowledge (we are securing this with making System Owner = me an expert but I am def. not there yet) 

We have tqo internal hours projects with about tenish task per project. 

MI understand I can move time, I am not understanding the aggregated but as long as you can see each week that would work. What do you do with the archived - hide them? 

All input is appreciated, I just made a temporary solution and let it brew until the migrating solution was working. 

[Jonas Falberg]

What I ended up doing for our business was creating a couple of "archive 2024" internal issues that I could move all the previous worklogs to. (I also just realised that the bulk move feature is NOT restricted to having just 10k worklogs per ticket)

The archived issues were created in our "internal issues" project, but they haven't been added to the Tempo settings so people can't log time towards them. They will remain in any exports and just be for historical and billing purposes.

I also turned on the aggragated worklogs feature but so far I'm doubting its effectiveness (at least for our setup), so I'm running a test on that over the weekend. Considering we're a fairly small company, at the current rate of worklogs being logged we'd reach the limit again within a year. That doesn't quite jive with the impression Susan gave above, but our use case might differ from Tempo's implementation. We'll see.

[Jonas Falberg]

So, I do think the aggregation is working as intended, but I have no way to monitor whether we are getting close to the limit now, I think?

On Friday I created 3 new worklogs in Tempo. And it seems to have combined them into a single 45 minute worklog (the top two updates, I assume, since I only logged 3), which is what I would have expected. However, It still registers as 3 worklogs in Tempo's reporting. I now don't seem to have any way to see how many worklogs an issue actually has. Is that correct?

[Kathryn Vargas]

@Paul York @Karin Kennergren @Michael Pohl @Linda Redgate @Muhammad Majeed @Joseph HANI @Mark Hawkins, @Iona Augustine, we sincerely apologize for the inconvenience caused by the Bulk Worklog Editor issues on December 9th and for the delay in addressing your comments here. We can only echo what @Muhammad Majeed said: thank you for your engagement and for helping the greater Tempo community through this thread. 

On December 9th, we observed a significant spike in bulk move operations, which led to the hanging issues many of you reported (@Paul York, what you suspected was spot on). Despite thorough stress testing, this unforeseen surge exposed limitations that caused the delays. Our team identified and rolled out a fix the same day, and operations should have stabilized by December 10th. If you’re still encountering issues, please let us know. As some of you already have done, we encourage you to reach out to our Support Team directly via the Tempo Support Portal for quicker responses in the future. 

We want to note that the bulk move operation may still take time depending on several factors, such as the number of worklogs. 

Once again, we apologize for the disruptions and delays in communication. We'll also be addressing other questions raised in this comment thread, please stay tuned. 

Thank you,
Kathryn Vargas
Product Manager (Tempo) 

[Kathryn Vargas]

@Garth Hume @Michaela Kubicová @Joseph HANI @Paul York @Karin Kennergren @AB Thank you for your feedback regarding deactivated users, which was indeed a limitation in our bulk move functionality.

We're happy to share that the team has implemented a fix: you can now bulk-move worklogs associated with deactivated users when Override Mode is enabled.

We apologize for the inconvenience this limitation caused, and look forward to hearing your thoughts on the solution.

Thank you,
Kathryn Vargas
Product Manager (Tempo) 

[Kathryn Vargas]

@Shawn Stevens I too am late to the party, apologies for the delay :( Regarding the points you brought up:

1. The two options you outlined are correct. Option 2 of deleting/moving worklogs could have been done through our Bulk Move Worklog editor or via Tempo API, freeing up "space" on the original INT-2, but Option 1 of creating a new Jira issue is definitely the quicker approach.

2. Regarding the status of the Aggregating Internal Issues' Worklogs feature, this article was originally published on August 22, 2024 when the feature was still in TempoLab. However, by the time of your comment, it had already been released to customers. We apologize for the confusion and have since updated the article to reflect the current status.

Best regards,
Kathryn Vargas
Product Manager (Tempo)

[Kathryn Vargas]

@Joseph HANI @Iona Augustine As you mentioned using Jira APIs, a reminder to please use Tempo's bulk worklog editor or the Tempo API for bulk moving and deleting worklogs, and not Jira's bulk move and delete worklog APIs. Using Jira's APIs for these actions may cause discrepancies between worklogs in Tempo and Jira.

This recommendation has also been outlined by Atlassian in both of their community posts: Upcoming changes: Introducing per issue limits for list fields in Jira Issues, Introducing Bulk Move and Bulk Delete Worklog APIs

In case you're still experiencing discrepancies, please don't hesitate to reach out to our Support Team directly via the Tempo Support Portal. 

Best regards, 
Kathryn Vargas
Product Manager (Tempo)

[Kathryn Vargas]

Hi @Jonas Falberg, happy to clarify the expected behavior regarding the count of worklogs. When aggregation is enabled for an internal issue, you will see one aggregated worklog per day on the Jira side, while all individual worklogs will remain visible on the Tempo side. 

So in your example, if you created 3 worklogs in Tempo on Friday, only a single worklog will appear in Jira. This is the intended behavior. 

Regarding the limit, it would take years (10,000 days) to reach the limit on the Jira side. While you'll be unable to see the breakdown of individual worklogs on Jira's end due to aggregation, you will always have the granular breakdown and detailed reporting in Tempo. Hope this helps!

Best regards, 
Kathryn Vargas
Product Manager (Tempo) 

[Mayuresh Athalekar]

@Kathryn Vargas _Tempo_ @Kathryn Vargas Moving the worklogs to another INT number also has limitations and i feel it's just emptying a full bucket to another bucket. However the new bucket also has 10k limitation which means i really need to create year wise buckets to make use of the original INT code. If this is true it's just a patch work or workaround and not solution.

Is this correct understanding ?

[Carlos Henriques]

Is the upgrade from 5k to 10k work logs limit live for everyone?

We started getting errors of issues hitting the work log limit, but after running the Logged Time report with the Work Log Count column, we don't have any tickets with 10k or more work logs. One of the tickets where we are getting the error "only" has 5800 work logs, so it should be fine if we limit was increased to 10k.