Skip to content

Assign an issue to a Release Tag

Release notes

Today customers are unable to show that issues are assigned to a specific version or Release outside of a Milestone. We now support associating a release to an issue directly from the issue UI.

Problem to solve

As a user, I want to associate a release to an issue using the application's UI, so that I can orchestrate releases outside of the scope of milestones.

Intended users

Most likely personas that will benefit from this feature:

User experience goal

The user should be able to assign a release to an issue from the issue sidebar.

Proposal

⭐ SEE PROTOTYPES ON FIGMA ⭐

  • In the sidebar of an issue, add a section for Releases below Iteration.
  • Default should display No releases when there is no association between the given issue and a release tag/item.
  • User should be able to click the Edit link to associate a release.
  • Clicking Edit should display a dropdown menu with group and project releases a user can choose from.
    • frontend use same dropdown from Group Releases
    • Group and project releases should ordered in sections, display the name of the project as title, and show a badge counter with the number of releases per group/project.
    • No release should be marked as selected in the dropdown.
    • User can associate only 1 (one) release per issue.
  • Selecting a release from the dropdown should close the dropdown and reload the section in the sidebar.
    • frontend A loading state should be displayed while the change is being applied.
    • The release section in the sidebar of an issue should display:
      • Name of the project
      • Release title
      • e.g. GitLab.Org / 13.5

Edge cases

When an issue moves to another a project or group that does not have releases:

We could potentially implement a solution that was initially suggested on #5135 (closed) : Prompt with a warning dialogue - You are moving an issue into a group that does not have X, Y, and Z releases. These will be removed from the issue if you continue - Move Anyways Cancel

Further details

Out of scope

Permissions and Security

Permissions should be consistent with the existing permissions structure regarding which roles can update milestones within a given Issue or MR.

  • Members with no access (0) should not be able to assign an issue to tag
  • Guest (10) members should not be able to assign an issue to tag
  • Reporter (20) members should not be able to assign an issue to tag
  • Developer (30) members should be able to assign an issue to tag
  • Maintainer (40) members should be able to assign an issue to tag
  • Owner (50) members should be able to assign an issue to tag

Documentation

We should probably update https://docs.gitlab.com/ee/user/project/milestones/index.html#overview and maybe even consider removing milestones as a child of Issues as we currently have both project and group level milestones (or making it more discoverable from either navigation menu).

Availability & Testing

  • We should consider putting this behind a feature flag during development.

What does success look like, and how can we measure that?

What is the type of buyer?

GitLab Starter +

Is this a cross-stage feature?

Yes, with devopsplan - @gweaver

Links / references

Edited by Rayana Verissimo