Change work item type within GitLab UI

Release Notes

Effortlessly change the type of your work items, giving you the flexibility to manage your projects more efficiently.

Summary

Users need the flexibility to change the Work Item type after creation to better reflect evolving project needs and improve workflow efficiency. This feature allows for seamless transitions between different Work Item types (e.g., issues, epics, incidents) without losing valuable information or context, enabling teams to adapt their project management approach as requirements change.

Common use cases

• Refining project scope: A team initially creates a user story as an issue, but later realizes it's more complex and should be an epic. The ability to change the Work Item Type allows them to easily upgrade the item without losing any existing information or having to recreate it.
• Breaking down large items: An epic might be determined to be too small in scope and would be better managed as a regular issue. The team can downgrade it, maintaining all relevant information and discussions.
• Correcting misclassification: If a team member accidentally creates a Work Item as the wrong type (e.g., creating an issue instead of an incident), they can quickly correct it without having to recreate the item and potentially lose valuable context or comments.
• Adapting to changing project needs: As a project evolves, the team might decide to change their workflow. For example, they might want to start using epics for features they previously tracked as issues. The ability to change types in bulk would streamline this process.
• Promoting prototypes or experiments: A team might start with a simple task or issue for a prototype, but as it gains traction and becomes a full-fledged feature, they can promote it to an epic to better manage its expanded scope.

Feature requirements

• Ensure that the behavior of this UI option for changing work item type is consistent with the existing /type quick action.
• Add Change type to the utility actions menu on work item detail page
• Open a modal form on Change type selection, with one field initially visible for type
  • If selected type does not support fields that have data entered, show a warning delineating fields that will be removed. Empty/null fields do not need to be noted.
  • If item has child items, and the selected type does not support child items of the same types, conditionally show a form option to handle those items. Options are delineated in #385131[Change_type.png]

Additional Information

• A quick action, /type has already been implemented (issue). This work is to introduce the option in the UI via the actions menu. We will not change the behavior already created for the quick action, simply make a UI option for it.
• When data from the source WIT doesn't correspond to a widget on the target WIT, we will write the data to the system notes and delete the data (ex. When an issue is changed to epic, the epic item cannot receive data from milestone, iteration, etc).

Design resources

• 🔍 View in Figma