nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to change global system kanban board sub-filter?

smark

All Kanban boards have now the sub-filter: "fixVersion in unreleasedVersions() OR fixVersion is EMPTY"

I don't knew where it comes from.

I am able to delete that filter for every single project but not for on one time.

Did you have an idear where that problem comes from and where i could delete that filter?

Accepted answers

All comments

Nic Brough -Adaptavist-

It's hard coded. The point of a Kanban board is that you move stuff to "done" and then "release when you're ready", which moves that stuff off the board. JIRA handles that by simply saying "when you release, you put a version on it". So the default Kanban filter is absolutely right for the standard desired behaviour of the board.

So, there's an easy question - what are you doing differently? What board filter do you actually want?

Kent Mingus

Nic, I have a similar issue. Let me shed some light on what is happening with me and I think with smark. In my case I am trying to use Kanban for marketing. Versioning and releasing a version does not make sense in this scenario. Many of our projects do not even use the fixversion field. The problem when you use the default value for the kanban filter: ixVersion in unreleasedVersions() OR fixVersion is EMPTY, both of these evaluate to false because the field does not exist. This results in my Kanban board missing issues that were created under another project and assigned to me. There doesn't appear to be a way to alter the filter. Seems like if you just deleted the entire sub-filter it would fix the problem but it just results in no issues selected.

Nic Brough -Adaptavist-

Yes, you need a way to bin things that are done off the board. Your usage doesn't have that. I'd suggest simply adding the version field to the project without bothering to put it on screens.

David Hergert _PAYX_

I would also like to see this. The issue we're seeing is, people create a few boards for a project and when one of them creates a Release to clear things from their boards, it disappears from everyone's board. So the default sub-filter is sub-optimal. We'd like to change it to something like

resolution is EMPTY OR (resolution is not EMPTY AND resolved &gt; -7d)

so as to have things drop off our Kanban board automatically after 7 days.

I just created https://jira.atlassian.com/browse/GHS-13180 for tracking this.

Nic Brough -Adaptavist-

As long as it's optional - people do need the Kanban boards to work as designed.

David Hergert _PAYX_

I agree, I think for teams that are pretty contained within their own project(s) and board(s), the current one makes sense.

Or even better, it'd be nice when you create a Kanban board you get the option to pick from a pre-defined (administrator managed) list of Sub-Filters based on the type of Kanban team you are (i.e. do you want to manually clear Stories with Releases, do you want closed Stories to automatically drop off after 7 days, or write your own sub-filter query).

Nic Brough -Adaptavist-

Yup - I think I'd be tempted to do it as a board config item though - "regularly sweep done column according to this (configurable) rule"

That's based on a sneaky trick that I've seen in business related projects that don't care about versions much - use an automation/service to run regularly and stick a fix version on issues that have been in the done column for a while.

Richard Cross

Sorry to necro this thread, but given Atlassian's own advice on keeping Kanban boards performant, I'm surprised the default sub-filter isn't:

fixVersion in unreleasedVersions("PROJ") OR fixVersion is EMPTY

So I've added a comment to https://jira.atlassian.com/browse/GHS-13180 with that suggestion. This is not to rule out David Heggert's suggestion below, but if that takes longer to implement, the above would at least keep large JIRA systems running smoothly without admins having to continually advise users on how to optimise their boards.

Matthias Bergmann_iixu5d

not everyone uses version ins Jira. We for example are not software developers, but lawyers.

Nic Brough -Adaptavist-

That's why I suggested "optional".

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration