Group milestones are searched differently in basic and advanced search, and the rules don't match the Group milestones page or any other search scope. We need to decide which levels of the group hierarchy a milestone search should return, so the two draft MRs that depend on it can be finished. ## Current behavior | Surface | Ancestors | Self | Subgroups | |---|---|---|---| | Basic search, instance level (`Gitlab::SearchResults#filter_milestones_by_project`) | n/a | n/a | n/a (project milestones only, no group milestones) | | Basic search, group level, group milestones (`Gitlab::GroupSearchResults#filter_milestones_by_group`) | Yes | Yes | No | | Basic search, group level, project milestones | n/a | n/a | Yes (projects in the group and all its subgroups) | | Basic search, project level (`Gitlab::ProjectSearchResults#filter_milestones_by_project`) | Yes (group milestones from the project's group and its ancestors) | Yes (the project's own milestones plus its group's) | n/a | | Advanced search, instance level | n/a | n/a | n/a (project milestones only, no group milestones) | | Advanced search, group level, group milestones | No (not searched at all yet) | No | No | | Advanced search, project level | No | Yes (the project's own milestones only) | n/a | | Draft https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260603 (advanced search), instance level | n/a | n/a | n/a (group milestones from every group the user can see) | | Draft https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260603 (advanced search), group level | No | Yes | Yes | | Group milestones page, HTML list (`Groups::MilestonesController`) | No | Yes | Yes (`self_and_descendants`) | | Milestone assign dropdown on issues, MRs and work items (project) | Yes | Yes | No | | Milestone assign dropdown on epics and group work items (group) | Yes | Yes | No | | Milestone filter bar on group lists | Yes | Yes | Yes | | Every other search scope (issues, MRs, work items, and so on), group level | No | Yes | Yes | Notes: - The ancestor rules in basic search came from https://gitlab.com/gitlab-org/gitlab/-/work_items/589711. Group milestones can be assigned at the project level, and the MCP server needs search to return the same milestones as the Milestone dropdown on MRs and work items. Milestones such as 19.4 are defined only in the top-level `gitlab-org` group, so before that change agents couldn't find them. - On GitLab.com, milestone search uses advanced search. So the use case from https://gitlab.com/gitlab-org/gitlab/-/work_items/589711 (searching a project for "19.4" and finding the `gitlab-org` milestone) doesn't work there today. That fix only applies to instances without advanced search. - Advanced search at project level never returns group milestones. The project-level filter matches on the document's `project_id`, and group milestones don't have one. This stays true with draft https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260603. - The MCP tool offers the milestones scope at instance, group and project level, so the decision needs to cover all three. - The Group milestones page list doesn't show parent milestones. For example, https://gitlab.com/groups/gitlab-org/ai/-/milestones doesn't show `gitlab-org` milestones. - Milestones are the only search scope that reaches up to ancestors. ## Constraint The MCP server calls the search API behind the scenes. We can't give MCP and the search web UI or API different behavior, so whatever we pick applies to all of them. ## Options Advanced search at project level needs extra work for any option that includes parent group milestones at project level, since today it returns none. 1. **Ancestors + self + subgroups** (`self_and_hierarchy`, like the milestone filter bar on group lists), in both basic and advanced search. Keeps the MCP use case working and also adds subgroup milestones. Con: it's the only search scope that looks upward, so rows from parent groups show up in a subgroup search, and advanced search needs an extra ancestor clause. 2. **Self + subgroups only** (like the milestones list page and the other search scopes). Simple and consistent with everything else. Con: it removes the MCP use case behavior from basic search. Searching a subgroup for "19.4" no longer finds `gitlab-org` milestones. On GitLab.com it doesn't work today anyway, because milestone search uses advanced search there. 3. **Keep basic search as it is** (self + ancestors, plus subgroup project milestones), and make advanced search match it. No change for basic search users. Con: group milestones of subgroups stay unsearchable, and the rule is hard to explain. 4. **Different rules per level.** Project-level search returns the project's milestones plus its group's and parent groups' milestones (like the milestone assign dropdown). Group-level search returns the group and its subgroups (like the Group milestones page and other search scopes). Keeps the MCP use case at project level. Con: group and project search follow different rules, and advanced search still needs work to return group milestones at project level. ## Decision needed Which levels should milestone search return for: - instance-level search, - group-level search, and - project-level search, in both basic and advanced search? Once that's decided, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260603 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260649 will be updated to match. ## Related - https://gitlab.com/gitlab-org/gitlab/-/work_items/589711 (added ancestor group milestones to search for MCP) - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260603 (draft: advanced search for group milestones, group + subgroups; on hold) - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260649 (draft: basic group search changed to group + subgroups, so basic and advanced search return the same milestones; on hold) @bastirehm @amandarueda @terrichu