### 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 1. Navigate to this example [Issue Board](https://gitlab.com/groups/gitlab-org/-/boards/4873470?not[label_name][]=product%20work&not[label_name][]=type%3A%3Aignore&not[label_name][]=UX%20Design&not[label_name][]=failure%3A%3A*&not[label_name][]=UX%20Paper%20Cuts&label_name[]=group%3A%3Aproduct%20planning&milestone_title=Upcoming). 1. Ensure that several issues have upcoming milestones. 1. Use the filter option to select `Milestone = %Upcoming`. 1. Observe that no issues are displayed, even though they have an upcoming milestone. ### Example |No milestone filter|Filtered by `milestone = %Upcoming`| |---|---| |[link](https://gitlab.com/groups/gitlab-org/-/boards/4873470?not[label_name][]=product%20work&not[label_name][]=type%3A%3Aignore&not[label_name][]=UX%20Design&not[label_name][]=failure%3A%3A*&not[label_name][]=UX%20Paper%20Cuts&label_name[]=group%3A%3Aproduct%20planning) |[link](https://gitlab.com/groups/gitlab-org/-/boards/4873470?not[label_name][]=product%20work&not[label_name][]=type%3A%3Aignore&not[label_name][]=UX%20Design&not[label_name][]=failure%3A%3A*&not[label_name][]=UX%20Paper%20Cuts&label_name[]=group%3A%3Aproduct%20planning&milestone_title=Upcoming)| | | | ### Additional information FWIW, the `upcoming` value works in a GLQL filter criteria: <details><summary>GLQL examples</summary> ```glql --- 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" ``` </details> ## Updated logic proposal _As agreed to in [this thread](https://gitlab.com/gitlab-org/gitlab/-/issues/429728#note_2182431608), 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| |-----|-------|------|-----|------| | :white_check_mark: | :white_check_mark: | - Tracking work with a defined timeline and clear start/end dates.<br>- For projects or sprints with specific start and finish points, providing clarity on progress and deadlines. | :white_check_mark: | :white_check_mark: | | :white_check_mark: | :x: | - Kicking off work without a firm deadline to encourage flexibility in delivery.<br>- Use when the start date is known, but the due date will be determined based on ongoing priorities or dependencies. | :white_check_mark: | :white_check_mark: | | :x: | :white_check_mark: | - Deadline-focused tasks where the end date is fixed but start time is flexible, like regulatory or quarterly deadlines.<br>- Used for milestones where only the completion is critical, helping teams prioritize around delivery. | :x: |:white_check_mark: | | :x: | :x: | - Tracking project milestones without set dates, like items needed to be completed before a public announcement.<br>- Projects dependent on the completion of other projects, where dates are unknown until other work is completed. | :x: | :x: | ### **Proposed issue filter logic for "upcoming" and "started" milestones** - **Upcoming**: - **Include** if `start_date > today` **AND** `end_date > today` - **Include** if `start_date > today` **AND** `end_date = NULL` - **Exclude** if `start_date = NULL` **AND** `end_date > today` (lacks a clear starting point) - **Exclude** milestones where both `start_date` and `end_date` are NULL, as these are intended for undefined timing. - **Started**: - **Include** if `start_date <= today` **AND** milestone is `OPEN` **AND** `end_date > today` or `end_date = NULL` - **Include** if `start_date = NULL` **AND** `end_date > today`, as a start date is required to define the milestone as "started" - **Exclude** if `start_date < today` **AND** `end_date < today` (milestone is effectively expired) - **Exclude** if both `start_date` and `end_date` are NULL to avoid non-timed milestones. ### Deprecation announcement :reminder_ribbon: We announced this change in %17.7 via https://gitlab.com/gitlab-org/gitlab/-/issues/501294.