<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> Service desk is the point of contact between users and service providers, as such, service desk is related to, yet has a distinct workflow from, software planning and development. In order to fulfill our [vision](https://about.gitlab.com/direction/monitor/service_desk/#vision) of providing a complete, yet lightweight and customizable service desk solution, we realized that we needed to create a separate work item from software product development. In this release, we are introducing a new work item type, "ticket", to enable us to build capabilities specific to service desk. In this initial release, in addition to the underlying architecture changes, we also are introducing a new concept, the requester. The requester is the person who has requested service or support and is someone that may be different from the author. Given that we are starting to change the layout of the ticket in an iterative fashion, we are also giving users and customers a way to not disrupt their existing workflow by allowing them to switch back to the legacy service desk issue layout. ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> Start the transition to work item based tickets ### User experience goal Avoid disrupting the existing user workflow while we move to the work item model. Add the ability to create tickets via API and UI and create a new widget for requester ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Migrate to work items along with issue work items feature parity work to reduce blockers on both sides and make switching over just a matter of the frontend view (so the underlying data is already migrated). Here's my breakdown of the work that needs to be done in order to migrate Service Desk issues to work items of type `Ticket`. I'll copy this to the description and change the issues under this epic accordingly and apply further details there in the next few days. ## Context 1. As part of the ~"work items::ga-issues" initiative we want to migrate Service Desk issues to work items of type `Ticket`. 2. A `Service Desk issue` is a regular issue where the author is the `support-bot` (`Users::Internal.support_bot`) and the `external_author` field (database field name is `service_desk_reply_to`) is `NOT NULL`. 3. Issues and work items can have `IssueEmailParticipant`s. They will notified about new public comments on the issue/work item. Email replies show up as a new comment (from external participant) on the issue/ticket. ## Feature parity We have almost reached feature parity: 1. :white_check_mark: `17.6` External participants via quick actions https://gitlab.com/gitlab-org/gitlab/-/issues/462118 1. Quick actions available 2. External participants warning below content editor 3. Notes from external participants display different notes header 2. :construction_worker: `17.7+` Requestor widget https://gitlab.com/gitlab-org/gitlab/-/issues/414317 1. Users can see the external author of a ticket in a widget in the sidebar. 2. Users can see the external author in the item list view. ## Remaining Roadmap 1. [Pre migration](https://gitlab.com/groups/gitlab-org/-/epics/11204 "Service Desk: Migration to Work Items (pre-migration)") 1. Scheduled for `17.7` and `17.8` 1. [Ensure issues and ticket work item types have the same set of widgets](https://gitlab.com/gitlab-org/gitlab/-/issues/505037) 1. https://gitlab.com/gitlab-org/gitlab/-/issues/414352+ 1. Service Desk list app (`project/-/issues/service_desk`) `app/assets/javascripts/issues/service_desk/components/service_desk_list_app.vue` accepts legacy Service Desk issues and work items of type ticket. 2. We don't intend to change the frontend app at this stage. 3. We'll introduce a workaround in `IssuesFinder` that will use the existing query and return both collections. This improved query should also fix this timeout problem https://gitlab.com/gitlab-org/gitlab/-/issues/496526+ 4. Allow `ticket` work item type on regular issue list and work item list (with filter by type). 1. [Emails to Service Desk will create work items of type ticket, not issues](https://gitlab.com/gitlab-org/gitlab/-/issues/421727 "Emails to Service Desk create work items of type Ticket, not Issues"). 1. Hide behind feature flag `service_desk_ticket`, but enable as fast as possible. 1. Because Service Desk issues and tickets use the same underlying data structure, we don't need to migrate data from one table to the other. 1. Once the frontend list app can consume tickets, we can create tickets for new Service Desk emails. 1. Can be deployed to gitlab.com after `IssuesFinder` change has been deployed. 1. [/convert_to_ticket creates ticket instead of SD issue](https://gitlab.com/gitlab-org/gitlab/-/issues/462437/) 1. https://gitlab.com/gitlab-org/gitlab/-/issues/414317+ 1. See above in `feature parity` section 1. We originally scheduled this for `17.8`, but I'd like to get the initial iteration out in `17.7`, because this will unblock ~"work items::ga-issues" and decouple it from the tickets migration. 1. This is the last blocker for switching the Service Desk issue view to work items view. 1. We'll need the requestor widget on both issues and tickets and only show it when data is available (because in iteration 1, the external author cannot be edited and so the widget doesn't make sense for regular issues except they were Service Desk issues). 2. [Migrate Service Desk issues to work items of type ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/414353 "Migrate existing service desk issues to tickets"). 1. Scheduled for `17.8`. 1. Because Service Desk issues and tickets use the same underlying data structure, we don't need to migrate data from one table to the other. 1. We only need to change the work item type of all legacy Service Desk issues. 1. This will require a batched background migration that collects all legacy Service Desk issues (from support bot `Users::Internal.support-bot` and `service_desk_reply_to` `NOT NULL`) and changes the work item type to `ticket`. 1. For gitlab.com we can do this whenever we want to. 1. For Self-Managed we aim for the [`17.8` release because this should be a required stop](https://docs.gitlab.com/ee/update/upgrade_paths.html). 1. We can handle all post-migration operations after the required stop in `17.9` and following. 3. [Post migration](https://gitlab.com/groups/gitlab-org/-/epics/11205 "Service Desk: Migration to Work Items (post-migration)") 1. Can be scheduled for `17.9+` 1. [Ensure all references in the docs are changed from `Service Desk issue` to `Ticket`](https://gitlab.com/gitlab-org/gitlab/-/issues/414838 'Change references in docs from "Service Desk issue" to "Service Desk ticket"'). 1. Maybe wait a release with the rest of the cleanup work? 1. [Clean up `IssuesFinder` workaround for legacy Service Desk issues and tickets](https://gitlab.com/gitlab-org/gitlab/-/issues/505024 "Clean up support-bot workaround in IssuesFinder") 1. [Migrate Service Desk list frontend app to work items](https://gitlab.com/gitlab-org/gitlab/-/issues/505027 "Migrate Service Desk list frontend app to work items"). 1. To be discussed: What kind of routing do we want to use? `/-/work_items/iid` or `/-/issues/service_desk/iid` (current) or `/-/service_desk/iid`? https://gitlab.com/gitlab-org/gitlab/-/issues/414314 ## Risks & mitigation 1. Work items don't show up in Service Desk list view any more 1. We change `IssueFinder` so that it returns both Service Desk issues and work items :thumbsup: 1. work items don't show up in regular list view 1. Allow ticket work item type on new work item list 1. Customers can see filter `type == ticket` but don't have tickets? 1. :shrug: 1. Ticket work items can be created from UI but are useless unless the requestor widget has been implemented in iteration 2 (external author can be added/changed) 1. Tickets behave like regular issues so not a big risk 1. Plan requestor widget MCV to `17.7` (instead of `17.8`) and iteration 2 to `17.8` or `17.9` ## Instrumentation 1. Add event for new ticket created from email 2. (Create event for new ticket created via UI) ## Why now? If we do the pre migration work and migrate Service Desk issues, we can release work item issues and work item tickets at the same time and can use the same "switch view" toggle etc. No need for any extra feature flag etc. <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- 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 -->