Board view for next-gen project showing 'Your board has too many issues'

[Andrew Haith]

The board for our next-project was visible yesterday, but as of sometime this morning (~9am BST), this message started appearing.

We have over 5000 issues in the project, but the board should only be including perhaps 100. We are unable to use the software at present due to this issue.

We have attempted to move issues out of this project into an archive one in the hope that we had just crept over some limit, but we have now without doubt removed many more than were added in even the past week, but the problem persists.

The only other change we made recently was to add a new status to the board. No items yet have this status. It's not now possible to access the board to edit its configuration to remove this status.

Is this a defect in the software, or do we have a broken configuration somehow?

[Jack Brickey · Accepted solution]

How many of the issues in your Project have a status other than ‘done’ (the last column on the right)? You can find this by running a JQL search.

project = myproject and status != done

replace myproject and done 

the point here is Done issues should be aging off the board after 14 days in that status.

[Andrew Haith]

Thanks for responding.

We have 953 issues which aren't 'done'. There can't be more than perhaps 50 issues which became 'Done' within the last 14 days.

Could adding the extra status option have interfered with this somehow?

[Andrew Haith]

OK. It seems our newly added column was added as the last column, so we probably do have > 5000 passing that query.

So how can we remove/reorder that column? The only way to do so seems to be through the Board, which we're now unable to get into.

[Jack Brickey]

LOL well that sure is a conundrum. Let me see if I can get you some help.

[Jack Brickey]

Given you are on Free you don't have access to official Support so I pinged some Atlassian folks to get more info or chime in here. TBH this seems odd that NG would always add the new status as the right-most column. I don't use NG much beyond testing and very basic projects at this point so I could be missing something obvious here.

[Andrew Haith]

Great. Thanks for your help Jack!

We may have deliberately positioned the new status as the last one, without realising that this would affect the workflow so drastically.

We're also looking to see whether we can bulk move some issues out to get under the 5k mark. I don't seem to have the permissions to do what's described here, but someone else in our org hopefully does.

[Andrew Haith]

FYI after playing with permissions, we've managed to bulk move some issues to an archive project.

We're now able to see our board again and have removed the offending column which was indeed the furthest right.

It seem like a fairly serious bug that the board can get into this state without any option to further modify the columns, however. Migrating issues might not be a possibility for all users.

Thanks again @Jack Brickey!

[Jack Brickey]

good work Andrew. I agree it seems like a bug. In fact I found this bug reported - JSWCLOUD-18037 

[Scott S]

We had the same issue occur on Friday, thank you for the detailed explanation here.

I have been trying to piece together the root cause; it appears that when you add a new column on a NextGen board, it adds to the right of the board. But why would this matter? Does this visual UI placement also mean that it gets mapped as "Done" in the workflow for the board?

• If it does, that seems like possibly unintended behavior, given the large impact it can have on the board.

  • However, it would be odd to have the right-most column on the board NOT represent the mapped workflow concept of "Done" so perhaps this is intended behavior.

• If it does not, it seems like the board should still be able to filter out the Done status issues with no trouble with a result set under 5,000 as the actual mapped statuses aren't changing.

I guess the question is, does the board's column placement ultimately drive any workflow mapping changes? And/or how does the Jira board and backlog perform its filtering whereby a result of over 5,000 would trigger the error?

We have deleted and retained a quantity of issues to guarantee the total number in the project is less than 5,000 but we'd like to confidently know how we can move forward without tripping this limit again.

We haven't yet raised a support ticket with Jira.

[John Wood]

We had this issue recently with a Scrum project board and were able to resolve it.

We have way had way over 5000 tickets for a while but that wasn't the problem.

For us, it was caused by someone accidentally changing the order of the columns in the board. It's possible to drag-move them from the board by mistake so quite easy to do. We were using a column for the "Done/Closed" status at the far right, and it had been accidentally been moved left.

I'm still not sure exactly why this caused the problem. My guess is that the right hand side now didn't cover all the closed tickets which added up to over 500? Not totally sure.

Anyway, the fix for us was to go to the project settings and move the Closed column back to the right.

Hope this helps someone else who hits this!