Service Desk "Ticket" Work Item Type
### 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). " --> ### 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)." --> For GitLab users, a service desk request or ticket is a container for all context needed to fulfill or review a request. For external users, a service desk request or ticket is the reference by which they can provide or seek out additional information for a given request. While a ticket is similar to a generic GitLab issue, the composition of widgets, the workflow, the requirements of a ticket are divergent. By creating a ticket work item type, we can do the following going forward: 1. Move away from relying on the author to determine if something is a service desk ticket 1. Build the necessary scaffolding to facilitate the ticket workflow e.g. introduce the concept of agent, requester, cc'd, conversation threads 1. Compose the ticket with specific GitLab widgets ### Proposal 1. Replace existing service desk issues with new ticket type (without making tickets too different from issues 2. Add capabilities to facilitate ticket workflows 3. Add necessary widgets to tickets ### Permissions and Security TBD ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? 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? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning --> ### Available Tier TBD ### Feature Usage Metrics TBD ### What does success look like, and how can we measure that? TBD ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers --> ### Links / references - https://docs.gitlab.com/ee/development/work_items.html - https://docs.gitlab.com/ee/architecture/blueprints/work_items/ - https://docs.gitlab.com/ee/development/work_items_widgets.html - https://gitlab.com/groups/gitlab-org/-/epics/6033+ - https://gitlab.com/gitlab-org/gitlab/-/issues/407470+ <!-- 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 -->
epic