Filtering issue boards by iteration only lists the first 100 iterations
Summary
When filtering an issue board by Iteration, the GraphQL response will not contain more than 100 entries. It seems to be ordered ascending, so once you have more than 100 iterations, you will stop seeing current/upcoming iterations and only be able to filter by increasingly outdated iterations.
Steps to reproduce
- Create more than 100 iterations in group.
- Go to issue board for that group.
- Filter by iteration.
- Observe missing iterations in the dropdown.
Example Project
See Cadences in https://gitlab.com/groups/gitlab-gold/mg-gold/-/cadences/ and try filtering in https://gitlab.com/groups/gitlab-gold/mg-gold/-/boards
What is the current bug behavior?
The list of filterable iterations is limited to 100, closed iterations are included and sorting is ascending, so that older iterations will always be included first. (Important to note – my sample data doesn't show the actual problem very well, because I created the iteration cadences very recently and all the missing iterations in the dropdown are far in the future. The actual problem a customer is experiencing is that their 100 iterations are all in the past and closed already, and they can't filter by current/upcoming iterations anymore now.)
What is the expected correct behavior?
Either being able to filter by all iterations, having a way to ignore closed iterations, or have the iteration sorted differently to allow access to more relevant iterations when filtering.
Relevant logs and/or screenshots
Last iteration you can filter by is ending Oct 5th.
Actual last iteration is ending Oct 19th:
Output of checks
This bug happens on GitLab.com
Workarounds
Search for the missing iteration by iteration title or cadence title
Next Steps
-
While we're listing items using dates as the primary field, the dates should be searchable. This is less about iterations and more about expectations in a searchable dropdown - it's expected that the primary values will be matched when searching.
- Searching on dates may still be valuable once we can make iteration names the primary field, though date matches should take lower priority than name matches (e.g. when searching "mar" an iteration titled "Marketing 12" should be first and an iteration titled "Security 8" with dates Mar 1-Mar 15 should be second). Matching dates when they're secondary is nice to have, but matching dates when they're primary is must have.
- We should prioritize current and upcoming iterations when creating a board list. There's limited use for a list for a completed iteration, and in most cases it's undesirable to move an item into that list (assign an item to a closed iteration) and as Gabe notes they will typically be empty. Moreover the list of completed iterations will grow infinitely making this unwieldy. I think it would be acceptable to hide closed iterations from this list.
- Because of the way boards work a list can be created while the iteration is upcoming, and it will still exist once the iteration is closed. You can't edit a board list to change the scope, but if you delete the list after the iteration is closed you can't recreate it. This is an acceptable quirk if a bit odd.
- The custom, one-off list pattern in boards isn't well suited to iterations. Because iterations will always be moving forward, with closed iterations flowing out and new iterations flowing in, creating a list tied to a specific iteration will always have temporary relevance. Being able to create a relationship between a board and a cadence and have all current+upcoming iterations appear as lists automatically (essentially group by: iteration) would be better suited, but significantly different from how boards work today. cc @nickbrandt - we're also looking at this from the perspective of a cadence page (prebuilt board w/ lists for iterations) but I'd expect we likely still need to support iterations in "regular" boards.
- A smaller iteration could be using dynamic pointers for iterations in lists, e.g. cadence > current, cadence > next, cadence > next+1. Going up to cadence > next + 3 (1 current + 4 upcoming) would satisfy a large number of use cases including the one noted here. That would replace specific iteration references and avoid having "stale" iteration lists that need to be swapped out.