Upcoming changes: Introducing per issue limits for list fields in Jira Issues

[Stefan]

Hello,

I too have many customers that have been using Tempo Timesheets with 'Internal Issues ' for many years, so I will have to check each for issue worklogs count, and implement some workaround. 

To find the worklog count, you can use this API path to return the total number of worklog entries for an issue: 

issue.fields.worklog.worklogs.length

I used it to import as a separate measure in eazyBI: 

// Check if the worklog object exists and it has worklogs
if (issue.fields.worklog && Array.isArray(issue.fields.worklog.worklogs) && issue.fields.worklog.worklogs.length > 0) {
    // Return the total number of worklog entries
    return issue.fields.worklog.worklogs.length;
} else {
    return 0;
}

At least that helps identify affected issues. 

Regards,

Stefan

[Cameron Barker]

Is there an easy method to disallow worklogs from being added to the old quarterly issues as I know hundreds of users would not move to the new issue perfectly?

A potential workaround is that I can move 1000 worklogs at a time to a different issue, so potentially I could archive to a new issue named "internal-meetings-2024-q1", I suppose I could write something to use the API and do this move. This seems pretty hacky, but at least I wouldn't have to update 50 issues a quarter manually.

[Daniel Menard]

@Shiraine Liu asking us to implement a pagination at the issue level is just offloading dev work from Atlassian to each of your customers. As a dev myself, I don't understand how your architecture is not able to handle more than a few thousand records per issue. It's not like we end up with fewer worklogs at the end by splitting it up by issue - so why isn't the system able to handle more on a single issue?

[Andrew Morin]

Interestingly enough is we are dealing with the worklog on single issues currently in Jira Data Center. The issue with performance or latency is not the worklog table but the changegroup & changeitem tables where the history is stored. We are logging time against "project" issues and found that if we clean up the rows in these two tables there are no performance issues even as we get over 100k rows in the worklog table. Not sure what value there is in logging the history of each time entry as it makes it really hard to see the history in the issue that really matters.

[Patrick Till]

Hi

These numbers seem reasonable.

Can we please have a filter that we can run to monitor any issues that are approaching this limit so that we may intervene in sufficient time.

[Yatish Madhav]

Thanks @Shiraine Liu  - I am with some of commentators here. If this limit is fast approaching, we should be allowed to filter with a JQL statement to see all issues where we need to take action prior to end-users facing the limit error. This is for all the new limits (worklogs, comments, etc)

I understand the REST API can help and I can do that too but I think many Jira/Project admins may not have the ability/understanding to do so quickly.

The email notification I got yesterday helpfully provided me issue IDs of issues that are either past or approaching the limit. It would be helpful

Thank you

[MW]

The limitation on worklogs sounds like a joke - as you can see a lot of people need it.

You should instead try to somehow archieve/soft delete logs older than some date instaed of limiting the numbers of logs in a single issue

[JaanusS]

@Shiraine Liu Does the linking limit apply to Jira assets also? Let's say for example is it a problem if we link an asset to 5000 issues?

[PBP]

Our organization has tailored our business around Tempos internal issues as well as ongoing fixed issues for invoicing customers. Larger customers attract more worklogs on this handfuld of fixed issues. Rotating these issue keys will not only result in employee dissatisfaction, but also result in confused customers. Not to mention we have to constantly monitor and take these new issues into account for any API integration we're using. To a large extent, we find the changes reasonable - but on a single issues throughout 2023, we have over 8.000 worklogs!

Thank god you stopped migrating existing issues before it hit any of ours.

As others have commented, IF the problem is to decrease the worklog data - how is this fixed by creating new issues adding up towards 5.000? We're still gonna have 8.000 entries - now on 2-4 issues instead of a singular. You're gonna have to provide better tools for this, rather than saying "just make an automation and rotate".

I'm sure our PowerBI consultant is going to have a stroke when he hears about this.

[Hans-Peter]

I agree to what my previous commenters said here. We are a small company and have issues with more than 9000 worklogs per year...

@Shiraine Liu  Did you think about agregating worklog data on issues per month/quarter/year older than a year/half year?

That could reduce the single (worklog) data entries per issue massivly. I know that this could only work with worklog data and is definitely tricky. But when I red through the comments here worklog data seems to me the only big problem with these new limits.

If an issue has more than 5000 comments than you should close it anyways immediately! :)

[Paul York]

I've just heard back from Tempo support, and it's not great. They reiterate that Atlassian is imposing this limit for performance reasons (something that we have never had an issue with at all) and tell us to rotate codes. 

We are a small company, and luckily, only one of our issues is affected by the maximum worklog rule. Still, we're growing our team, and this will become increasingly problematic, requiring fundamental changes to our daily/weekly/monthly workflows (with two weeks' notice!).

We can't jump ship to another platform as JIRA is such a good tool and is so entrenched in our working lives, but all of a sudden, we're going to have to actively manage something we never used to worry about, which is something we never wanted to get into.

One hope I had was that Tempo support directed me to their Bulk Worklog editor to move off a maximum of a thousand worklogs at a time to another issue.  Whilst a little clumsy doing this piecemeal, I'd hoped to archive enough older worklogs to allow us to continue working, but this tool fails to move anything where the original account is no longer active, and therefore you need to pick each individual worklog to move which is no longer a practical way forward.

We need a better option for managing issues where the worklogs are now too large due to this arbitrary limit :(

[Jennifer Fölster]

Hello Atlassian-Team,

in your comments I read "Updates of existing worklogs will still be possible when the issue has reached the limit. The changelog has been updated with the correct information."

Can you please specify if it will also be possible to add new worklogs on existing issues, or if it will only be possible to change existing worklogs?

We also use Tempo and have several internal issues that exceed the worklogs limit.

It would be very helpful to at least being able to add worklogs on existing issues. The suggested workaround about monthly adding new issues for internal worklogs will be very inconvenient for both our users and administrators. Also, reporting about time tracking will become much more complicated.

It really is a hassle to proceed these changes within a 2 weeks period.

Thank you for your understanding and kind regards,

Jennifer

[ET03238]

As everyone else said, this is affecting our company a lot for the worklog part, since we are using tempo timesheet with the internal issues that have way more than 5000 worklogs.

Please help us with this, the workaround proposed until now are not good enough, maybe atlassian should reach out to tempo to solve this problem, this is clearly impacting a lot of customers.

[Muhammad Akram Sharifi]

Hi, 

What will happen if the issues have already reached the Time log limit? will the oldest logs will be deleted? Or logs will be deleted for some time?

can someone explain

[Julia Foden]

I am in the same boat as many here, using Tempo. Two weeks' notice to come up with a viable solution is unacceptable.

[Maureen Ipchi]

Hi @Shiraine Liu 

Will Jira permit the update of existing worklogs if the issue already has more than 5K worklogs?

[Fredson Nogueira da Silva]

Hello everyone,

Our organization uses Tempo Planner for vacation and absence planning, with approximately 100 Jira users. 

I’m wondering how these new limits will affect our Tempo Planner records. Has anyone already looked into the impact of these changes on capacity planning and resource management in Tempo Planner?

Thank you in advance for your insights and experiences!

[Nguyễn Phương Quỳnh]

Hi supporting team,

Is 1 worklog of child issue consider as 1 worklog of parent epic? Or the limit are separated between child issue and parent epic?

Our organization is planning to create periodical child issues under common epic so that worklogs will be put under each child issue instead of original overload epic. But not sure if it's allowed based on your logic.

Thanks!

[AVB]

Hi,

I'm really concerned about this change. We cannot tell all our users to use new issuekeys to log the same activities, it just doesn't make sense. 

If we have no choice than create new issues, is there a way to exchange/reverse the keys? In Susan's example just above, let's imagine another issue INTERNAL-100 is created for same purpose -> is there a way to force INTERNAL-1 to become INTERNAL-100 and vice-versa so that the real users do not have to change their way of working and that there is enough free room for oncoming worklogs/comments?

Aurélie

[Siddharth Ninan]

What Tempo documentation fails to specify is that bulk worklog delete/move will not work on approved worklogs!

For the bulk delete to work timesheets need to be in re-opened state.

Also there is no easy way to bulk reopen timesheets except using rest api. The rest api too appear to only open 1 timesheet per api call.

There is no easy way to bulk archive/delete/move worklogs that have exceeded the 5K threshold.

[Timo Kinder]

Hi, 

we just realized that we can get the total number of worklogs using the API: "/rest/api/3/issue/[issueID]/?fields=worklog".

But that's still not a solution, cause it is not possible to use this in Jira-automation as smartvalue to create a rule for affected issues. Automation seems to stop at "maxResults=20"...

Please make the total-counter a smartvalue, so that at least we can KNOW what issues will be affected, soon.

Thanks and cheers,
Timo

[Maor Levinas]

Hi All,

Here is Tempo's answer, which you may find useful

" The workaround suggested by Atlassian would be to create a new issue periodically to help manage the worklogs. We have suggested this when clients start noticing performance issues due to issues with a long history.

Instead of deleting the worklogs (as this can cause discrepancy), we would advise you to bulk move them to a new issue, so you can continue to use the issue key people are already familiar with without losing the history. https://help.tempo.io/timesheets/latest/moving-worklogs-in-bulk

To bulk reopen all timesheets, the workarounds would change the Period Approval, at Tempo >> Settings >> Period Configuration.

• Change it from Weekly to monthly or vice versa
  • All timesheets will be reopened automatically
• Move/delete the worklogs
• Revert the period configuration to the previous setup,
  • The status of the Timesheets will be reverted as well.

Please note that we usually do not advise on this, but given the urgency, bulk open timesheets are the quicker way to do so.

In addition, our Production and Dev teams are looking into other possible solutions, so if you want to hold off a bit until we check all possibilities, please let us know, and we will inform you as soon as we have any updates."

[Paul York]

The problem with this workaround is it doesn't work as seamlessly as you'd hope.

Where users have left, or Tempo accounts have been closed, the bulk edit fails to move the worklogs, so for organisations that have been using single issues for time logging quite happily for some years, it isn't possible to bulk-move and avoid everything failing at the end of this month. :(

We have a support ticket open with Tempo now to try to find a workable workaround, but so far, we haven't found anything.

[Daniel Menard]

Thanks for sharing the workaround @Maor Levinas . It sounds like given a little more time Tempo could make transferring the worklogs reliable and maybe automated.

The inability to bulk edit worklogs for old accounts is definitely a blocker in our case though. I would have hoped the bulk edit tool could just directly query and update the database but it sounds like there are lots of extra restrictions that prevent it from happening.

[Julia Foden]

Echoing what @Timo Kinder said about smart values. My idea was to run a quarterly automation rule to check these dedicated time-tracking issues: if the worklog size is approaching the limit, create a new issue and close the old one appending "Closed. Use <new issue key>" to the summary. But there's no smart value for worklog size! 

{{issue.worklogs.size}} returns 20 because there are max 20 on a page. What a joke.

@Shiraine Liu this is shocking really. Not only are you forcing us to scramble for workarounds with only two weeks' notice, you're not providing us with the tools to create these workarounds. 

I have booked a call slot for next Tuesday. And in the meantime I will experiment with using Automation to send an API request to get the worklog total.

Edit:

So I've got the web request from Automation to fetch the worklogs total. So far so good. And Atlassian's email helpfully provided a list of issues that are currently at >4500 worklogs. So I tested the rule on an issue with 4828 worklogs. BUT the rule fails because

"The response received from the remote server exceeded the maximum allowed response size:

Response content size of 11702028 bytes exceeded maximum allowed content size of 10485760 bytes"

@Shiraine Liu 

Can you please pause the rollout of this change until there is a usable smart value for worklog size?