Create Service Desk tickets from the UI and API (#433376) · Issues · GitLab.org / GitLab · GitLab (original) (raw)

Skip to content

• • Why GitLab
  • Pricing
  • Contact Sales
  • Explore
• Why GitLab
• Pricing
• Contact Sales
• Explore
• Sign in
• Get free trial

Create Service Desk tickets from the UI and API

There's still the need of an internal agent creating an issue on a requester's behalf.

Because we don't have the Ticket work item type in production yet, I'd like to deliver a lightweight workaround for users to create Service Desk issues from the UI.

Proposal

1. Add a quick action e.g. /convert_to_ticket user@example.com that transforms an issue into a Service Desk issue (also makes it confidential) and adds user@example.com as author and external participant.
2. Also adds a confidential comment with details (who was the original author, who was added as the new external author) and/or a system note that says @root made this a Service Desk Ticket.
3. We won't send a thank_you email. Or we could add a parameter /convert_to_ticket user@example.com --thank_you to the command to also send the thank_you email.

There is a POC MR that adds the quick action /make_service_desk_issue, transforms the issue into a Service Desk issue and adds an internal comment.

E.g. quick action (uses old /make_service_desk_issue name)

E.g. internal comment after transformation

Why?

1. Raising a Service Desk issue on behalf of someone else can be found on a number of customer requirements. For example:
   1. A support engineer wants to spin up a second support ticket to better differentiate between the two things a customer was talking about in the initial ticket.
   2. Someone received an email to a personal or shared mailbox that could be better handled in a ticket.
2. After switching to the work item framework and implementing the "Ticket" work item type, users can add tickets through the UI. To fill the gap until we're there, this can be a MVC and boring solution to fulfill that JTBD. We'd have another way to add Tickets via the UI after the migration, so we could safely remove the quick action later (or keep it, see comments below). Two scenarios come to mind after the work item migration:
   1. Deprecate the quick action and remove it after the migration
   2. Keep the quick action to allow to change the work item type after the item has been created. (recommended from comments below)
3. It's fast to implement and right now there is no workaround available for this.
4. We could even allow users to add Service Desk issues via API. They would add an issue and then add a note with the quick action which would make it a Service Desk issue. The work for the API integration also depends on the work item migration.

Why not?

1. After switching to the work item framework and implementing the "Ticket" work item type, users can add tickets through the UI. Users need to understand that there is now a new way for this JTBD.
2. We knowingly add a small feature that'll eventually be removed after the migration. But we don't know when Service Desk issues will be migrated to Tickets.
3. What if users want to get the normal issue back? We probably won't offer a similar action for /make_issue @author

Edited Jan 25, 2024 by Marc Saleiko