Add visibility and subgroup filters to groups GraphQL queries

Colin Jacob Bobyrequested to merge
gitlab-community/gitlab-org/gitlab:609450-add-groups-visibility-and-subgroups-filters into master

What does this MR do and why?

Exposes two filters on the groups GraphQL queries: visibilityLevel and includeSubgroups.

GroupsFinder already supports both, as visibility and include_parent_descendants, but neither was reachable from GraphQL. This adds them to BaseGroupsResolver, so they become available on Query.groups, Query.adminGroups, and Organization.groups.

Both arguments map onto the existing finder params with the as: option, following the owned_only argument already in that file, so resolve_groups and its GroupsFinder call are unchanged.

includeSubgroups only has an effect alongside parentPath. On its own it is a no-op, which matches how GroupsFinder already treats include_parent_descendants when no parent is given.

This is the GraphQL prerequisite for the list_groups MCP tool.

Screenshots or screen recordings

Not applicable, no user-facing UI change.

How to set up and validate locally

# Filter by visibility level
query {
  groups(visibilityLevel: PUBLIC) {
    nodes { fullPath visibility }
  }
}

# All descendants of a group, not just direct children
query {
  groups(parentPath: "some-group", includeSubgroups: true) {
    nodes { fullPath }
  }
}

Without includeSubgroups, the second query returns only the direct children of some-group.

MR acceptance checklist

  • Resolver spec covers both arguments, including the no-op case where includeSubgroups is passed without parentPath.
  • Request spec coverage was added to the shared groups query examples, so it runs against both Query.groups and Query.adminGroups.
  • doc/api/graphql/reference/_index.md regenerated with bundle exec rake gitlab:graphql:compile_docs.
  • No breaking schema change: both arguments are new and optional.

References

Merge request reports