Skip to content

New Issue epic search incorrectly scoped to top-level group for nested projects on 18.4.0

Summary

On GitLab 18.4.0, when creating a new issue in a project that is nested within several subgroups (i.e. top-level-group/subgroup/sub-subgroup), the "Parent" search in the sidebar is incorrectly scoped. It only searches for epics in the top-level group, preventing users from assigning epics from the project's immediate or intermediate parent groups during creation. Note that the Parent dropdown works correctly after the issue has been created. The problem seems to be localized to the issue creation screen.

An investigation using browser network tools confirmed the frontend sends a GraphQL groupWorkItems query where the fullPath variable is incorrectly set to the top-level group's path instead of the project's immediate parent group. This behavior was successfully reproduced in a test environment with a three-level group structure (Top Group > Subgroup > Project), but it is not yet clear what the specific trigger for this incorrect scoping is. One factor present during replication was naming the project identically to its parent group, but this may not be the sole cause.

Steps to reproduce

  1. On a GitLab EE 18.4.0 instance, create a nested group structure: Top Group > Subgroup A > Subgroup B > Project B.
  2. Create an epic in Top Group named "Top Level Epic".
  3. Create an epic in Subgroup A named "Subgroup Epic".
  4. Navigate to Project B and click the button to create a New Issue.
  5. In the sidebar on the right, click the "Parent" dropdown.
  6. Search for "Subgroup Epic".
  7. The subgroup epic will be missing, and only the top level epic will be shown as an option.
  8. Continue creating the issue without assigning a Parent.
  9. Click the Parent dropdown on the newly created issue and notice that the top level epic AND the subgroup A epic are now shown.

Example Project

What is the current bug behavior?

The search for "Subgroup Epic" returns no results. Only "Top Level Epic" is visible and searchable in the dropdown.

The network request shows that the GraphQL query might be incorrectly scoped. The variables object for the groupWorkItems operation is sent with the fullPath of the top-level group:

"variables": {
  "fullPath": "top-group",
  "searchTerm": "Subgroup Epic",
  "includeAncestors": true,
  ...
}

What is the expected correct behavior?

The epic search should find and display epics from the project's immediate parent group (Subgroup A) and all of its ancestors (Top Group). Both "Subgroup Epic" and "Top Level Epic" should appear in the search results.

The variables object for the groupWorkItems GraphQL operation should be sent with the fullPath of the project's immediate parent group:

"variables": {
  "fullPath": "top-group/subgroup-a",
  "searchTerm": "Subgroup Epic",
  "includeAncestors": true,
  ...
}

Relevant logs and/or screenshots

.

The key evidence is the incorrect GraphQL payload described above. The customer also observed that the search works correctly when editing an issue after it has been created, which points to the bug being isolated to the "New Issue" view component.

Output of checks

This bug was reported by a customer on a self-managed GitLab Enterprise Edition 18.4.0 instance.

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

The below is an AI generated explanation, so take with a grain of salt

The bug is likely located in the frontend Vue component responsible for the "New Issue" page sidebar. The logic that determines the parent group's fullPath to be used as a variable in the groupWorkItems GraphQL query is flawed in projects nested within multiple subgroups. The root cause appears to be in how the component resolves the project's parent path.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖