[go: up one dir, main page]

Skip to content

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

  1. Navigate to this example Issue Board.
  2. Ensure that several issues have upcoming milestones.
  3. Use the filter option to select Milestone = %Upcoming.
  4. Observe that no issues are displayed, even though they have an upcoming milestone.

Example

No milestone filter Filtered by milestone = %Upcoming
link link
Screenshot_2024-10-19_at_12.07.18_a.m. Screenshot_2024-10-19_at_12.07.44_a.m.

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 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

🎗️ We announced this change in %17.7 via #501294 (closed).

Edited by Amanda Rueda