Implication of Kanban board setting "Hide Completed Issues Older Than..." filtering is misleading

[Isaac "Link" Linkletter, A-CSM]

TL;DR - Setting implies it is filtering on "resolution" or "resolutiondate" fields, when it is actually filtering on "updated" or "updatedDate" fields.

Long Version - With a Kanban board using this filter, normally there's no problems, and the feature appears to work as expected (as long as issues follow only the happy path from creation to resolution). Users see issues completed more than 1 or 2 weeks ago disappear from the Done column on the board, and everything is nice and tidy.

Then, your team, organization, or company makes a change of some type to how Jira is used, and a set of issues are bulk updated to meet the new expectation. Suddenly, the Kanban board is flooded with issues closed weeks, months, or even years ago. Developers are having trouble finding their next ticket, project managers are panicking due to the appearance that many items were reopened for some reason, and everything is terrible, especially because there's no way to correct the issue, other than just telling everyone to suffer through it until the week passes, and the issues disappear again (see screenshots included below).

Kanban Board Filter Settings (sensitive information redacted)

Kanban Board with old issues reappearing after bulk edit (sensitive information redacted)

While the phrasing of the setting is confusing and misleading, especially combined with the help text of "Speed up your board by hiding issues you're no longer working on." below it, the real issue is that the standard expectation is that the phrase "completed older than..." implies that the feature is looking at the issue's completion/resolution date, not the date when the issue was last updated.

While the easiest solution to this confusion would be to change the label and help text for the feature (i.e. "Hide Closed Issues Updated Longer Ago Than..."), the desired behavior, hiding issues with a no-longer-important resolutiondate, is still not met, and any subsequent bulk updates will cause the reappearance of old issues, and reintroduction of confusion to the development team.

[Omar Rashid]

Yup this def seems to be an issue. Causes severe performance issues on a kanban board in a scenario where it is set to hide older issues but those thousands of issues show up because the project was changed from one project to another, therefore 'updating' the issue..

[Nic Brough -Adaptavist-]

No, sorry, I don't doubt you, I was fishing for more info in a really badly phrased way.  Your screenshot is great, tells me that that issue should probably not be there.

However, there's something not appearing on the wider view that I would expect and it might be the problem.  Could you open up the full issue view and have a look at a couple of things more?

• Check the main part of the view where the "system" fields appear (like status, issue type, etc).  What is the current resolution of the issue?
• The history tab - can you check what and when each change of the resolution was?

[Isaac "Link" Linkletter, A-CSM]

Not to my knowledge.

[John Funk]

Hey @Isaac "Link" Linkletter, A-CSM  - Did you ever get this resolved?

[Chris Henk]

To follow on from Detlef Steinhäuser comment above uncategorized statuses are caught up in this filter as well.  We had statuses in the middle of the workflow that were not categorized and this results in the issues dropping off of the board even though they are not resolved and in a column in the middle of our board.

[Detlef Steinhäuser [Communardo]]

This behavior is not only linked to the update date. The status category seems to be used as a further criterion.

It is strange to decide this on the category, because there are many cases where I want to map only a part of my process with the kanban board.

[Isaac "Link" Linkletter, A-CSM]

Sure thing! Here is the detail view of the issue highlighted in my original post.

System Fields:

History:

I'm interested to know what you think might be going on, so I look forward to your response

[Isaac "Link" Linkletter, A-CSM]

Maybe I misspoke above. No one in our organization is bulk editing the resolution, they may be bulk-adding a label, or bulk-changing the fix version. Those changes, however also modify the updatedDate field (to whenever the bulk edit occurred), and since the filter setting in question appears to be filtering based on updatedDate instead of resolutiondate, while the resolutiondate of those bulk edited issues does not change, they reappear on the Kanban board because their updatedDate is now less than the filter cutoff.

I'll edit my post above to include a sanitized screenshot from my organization's Jira. Hopefully that will further clarify things.

[Patrick Constantine]

Found this conversation for exactly the reasons you've detailed.  I did a bulk change on items in order to be able to make a filter change, and because all the closed items were affected by the change, the "updated" date changed and I was suddenly drawn to the fact that it doesn't use "resolved" at all.

[Nic Brough -Adaptavist-]

So the boards I'm working with all use "resolution date", not "updated".  I'd question why people are using things that bulk-clear or bulk-change the resolution when they don't need to.