Filtering with Milestone = %Upcoming not working
Summary
When users filter Issue Boards by Milestone = %Upcoming, no issues are displayed, even if issues exist with upcoming milestones. This filtering behavior deviates from expected functionality, where all issues with the "upcoming" milestone should appe on the board.
- Expected Behavior: When the milestone filter is set to "Upcoming," all issues associated with upcoming milestones should be visible on the Issue Board, just like they would be for other milestone filters.
- Why it matters: Proper milestone filtering is critical for project management in GitLab. Teams rely on Issue Boards to plan work for upcoming milestones, and the current bug can lead to confusion and missed tasks.
Steps to reproduce
- Navigate to this example Issue Board.
- Ensure that several issues have upcoming milestones.
- Use the filter option to select
Milestone = %Upcoming
. - Observe that no issues are displayed, even though they have an upcoming milestone.
Example
No milestone filter | Filtered by milestone = %Upcoming
|
---|---|
link | link |
![]() |
![]() |
Additional information
FWIW, the upcoming
value works in a GLQL filter criteria:
GLQL examples
---
display: table
fields: title, milestone, assignees, healthStatus, updatedAt
---
project = "gitlab-org/gitlab" and label = "group::product planning" and milestone=upcoming and label = "workflow::ready for development"
Updated logic proposal
As agreed to in this thread, below is the updated logic we will use for %upcoming
and %started
values.
Start date present | Due date present | Use case | Include in %Upcoming | Include in %Started |
---|---|---|---|---|
- Tracking work with a defined timeline and clear start/end dates. - For projects or sprints with specific start and finish points, providing clarity on progress and deadlines. |
||||
- Kicking off work without a firm deadline to encourage flexibility in delivery. - Use when the start date is known, but the due date will be determined based on ongoing priorities or dependencies. |
||||
- Deadline-focused tasks where the end date is fixed but start time is flexible, like regulatory or quarterly deadlines. - Used for milestones where only the completion is critical, helping teams prioritize around delivery. |
||||
- Tracking project milestones without set dates, like items needed to be completed before a public announcement. - Projects dependent on the completion of other projects, where dates are unknown until other work is completed. |
Proposed issue filter logic for "upcoming" and "started" milestones
-
Upcoming:
-
Include if
start_date > today
ANDend_date > today
-
Include if
start_date > today
ANDend_date = NULL
-
Exclude if
start_date = NULL
ANDend_date > today
(lacks a clear starting point) -
Exclude milestones where both
start_date
andend_date
are NULL, as these are intended for undefined timing.
-
Include if
-
Started:
-
Include if
start_date <= today
AND milestone isOPEN
ANDend_date > today
orend_date = NULL
-
Include if
start_date = NULL
ANDend_date > today
, as a start date is required to define the milestone as "started" -
Exclude if
start_date < today
ANDend_date < today
(milestone is effectively expired) -
Exclude if both
start_date
andend_date
are NULL to avoid non-timed milestones.
-
Include if
Deprecation announcement
Edited by Amanda Rueda