Assign an issue to a Release Tag

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

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 🤖 GitLab Bot 🤖