### Problem to solve <!-- What problem do we solve? --> #### Customer Value > * because they are missing "Task" type issues, they are currently modelling user stories as epics and use issues only for Tasks > * consequence is that they can't use milestones and burn-down charts or iterations for user stories, which isn't ideal > * this also is an issue in Value Stream Analytics, because it works with issues, not epics > * tried using Epics for OKRs as well, but that does not work well for cross-cutting (cross group) initiative **Goal:** Improve the user task success and satisfaction scores for the process of creating children of user stories by a minimum of 40%. **Note:** Because we do not have parent/child relationships on issues yet, `Task` will have a link type of `related` for this MVC. #### Internal Value - Incrementally iterate on new, single FE Vue App as part of the longer-term strategy to pay down product and technical debt on the exiting issue view. - Incrementally, iteratively work towards the goals of the [Work Items Initiative](https://gitlab.com/groups/gitlab-org/-/epics/6033) ## Proposal Convert a markdown taskable to issue of type `Task` with link type of `related` from within the existing issue detail view. Prevent tasks from being created through the current issue creation flow. ## UX Screens View recording of prototype here:  Steps noted: * User hovers (desktop) or taps (mobile) on the MD list item and seen an option to "Convert to work item" * Selecting this option launches a modal with an editable version of the title and type. Also shown here is Weight and Assignee (are these MVC?) * Saving as-is makes the task convert to a work item with a badge showing the type * Work item is added as a Related item **QUESTION:** Have we designed any error states / toasts / user feedback when an error happens for the new work item UI? We'll need that for this issue if there is an error when creating the issue. ## Acceptance Criteria - [x] Clicking on a button next to a markdown taskable opens the new work item modal/sidebar (create mode). - [x] The title is prefilled with the text string from the markdown taskable. - [x] The title can be changed from within the modal before clicking create. - [x] Successfully creating the task closes the modal and replaces the markdown taskable plain text with a GFM reference to the issue of type `Task`. - [x] Clicking cancel or clicking out of the modal cancels the creation process and closes the modal/sidebar. - [x] If there is an error when creating, the Task detail view provides context to the user. - [x] Styled appropriately for Mobile and Desktop. - [ ] Snowplow tracking implemented ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> - Same permissions as existing issue permissions. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> - Yes ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> - E2E test for converting markdown taskable to issue of type `Task` ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> - Count of `Task` created weekly/monthly - Count of MAU creating `Task` weekly/monthly ## FE Event Trackers Structured event taxonomy: https://docs.gitlab.com/ee/development/snowplow/#structured-event-taxonomy When the "convert to task" button is clicked: ``` category: workItems:show label: work_item_create action: click_markdown_taskable_create_button property: [type_{{insert issue type}}] ``` Note: `[type_{{insert issue type}}]` is intended to future proof this tracker a bit as we will likely allow the selection of type prior to the modal/sidebar at some point in the future. We can hard code this for now if we remember to update it when/if this happens later :smile: When the work item is successfully created. Do not fire event until success from server: ``` category: workItems:new label: work_item_create action: create_work_item_success property: [work_item_type_{{insert issue type}}] ``` When the work item creation process is cancelled (clicking cancel OR mousing out): ``` category: workItems:new label: work_item_create action: create_work_item_cancelled property: [work_item_type_{{insert issue type}}] ``` ### Implementation Steps **MR 1, UI**: * [x] Add button to `Convert to Task` * [x] Make button open modal/sidebar with new work item detail view (create mode) * [x] Prefill title with text from markdown taskable and auto-focus keyboard/cursor on the title input * [x] Clicking out of the modal/sidebar before creation cancels the process * [x] Click cancel in the modal/sidebar cancels the process This part will require a bit of refactoring on the router logic on create view. Instead of redirecting to the previous route, we'll need to close the "sidebar modal" **MR 2, working with API**: * [ ] Click create uses the `createWorkItem` mutation * [ ] After creation, replace the markdown taskable text in the description with a GFM issue reference to the newly created Task. * [x] Provide a way for the user to understand any errors if they happen when clicking create. Currently, the Create view already utilizes `gl-alert` component to show an error on `createWorkItem` mutation. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->