馃殌 Create a new Task work item from Markdown Task
## Follows - [Show additional meta-data in issue reference in rendered GFM](https://gitlab.com/gitlab-org/gitlab/-/issues/345170) ## Problem There is no way to create an issue type of `Task` from an existing issue ## Proposal ### Now Shameless MVC to make this capability general available: - Expose a button to convert markdown checklist item to Task work item. [See how GitHub handles this](https://gitlab.com/gitlab-org/gitlab/-/issues/2036#note_646045173) - The `Task` work item is related to the issue (work item of type `Issue`) and is visible in the "linked issues" section of `Issue` ### UX - In this mockup, the icon is paired with the re-ordering icon, which will be implemented as part of https://gitlab.com/gitlab-org/gitlab/-/issues/15260 ![Screen_Shot_2021-11-15_at_3.29.35_PM](/uploads/11a39b9a396af0b721ffda6b3acb510b/Screen_Shot_2021-11-15_at_3.29.35_PM.png) ![Screen_Recording_2022-01-18_at_11.26.53_AM](/uploads/45697c745edb611ed6d36e22d73ed5db/Screen_Recording_2022-01-18_at_11.26.53_AM.mov) ### Later Later on: - Product planning can migrate Task to be an "official" child on an issue for Premium+ customers. - Product planning can integrate whatever new relationship management UI they deem necessary into the legacy issue view and new work item detail view. ### Not in scope - This functionality will only exist on `type === Issue` - Tasks cannot be created from the general issue creation flow ### Fringe cases to clarify - If the issue of type `Task` is in an issue and I right-click and select "Copy Link", then enter that URL into the `Linked Issues` in another issue, what happens? - If we show issue of type `Task` in the issue list, what happens when you click on that particular issue to open it? ## Tier - ~"GitLab Core" if `Task` is just a related issue. - `Task` is just a type of Issue and [we've already made the decision](https://gitlab.com/gitlab-org/gitlab/-/issues/323404#note_521563531) that default issue types (can't change type name, can't customize anything, no hierarchy of types) will be in ~"GitLab Core" so we can make types "work by default" for all GitLab Projects. - ~"group::product planning" can decide how to tier the parent/child stuff. This does expose the need to have issue types support different types of relationships depending on tier. ## Implementation Steps - [ ] ...engineering task here
epic