Draft: [POC] Service Desk issues and incidents use legacy detail view (!174167) · Merge requests · GitLab.org / GitLab

What does this MR do and why?

Contributes to Ensure incidents and Service Desk issues use le... (#502823 - closed)

Service Desk issues and incidents use legacy detail view

With the feature flag work_items_view_preference we allow users to switch to the new work item view for all issues and work items using the user preference use_work_items_view.

This change ensures Service Desk issues and incidents continue to use the legacy view even if the view preference for work items is enabled.

This involves all workflows related to incidents and Service Desk issues:

Create workflow
List and browse to detail view
Detail view

Feature flags and migration to work items path

The change doesn't care about the 🎏 feature flags work_items_alpha or work_items_beta and so just respects the type. Once we start work on actually migrating to work item incidents or tickets we can guard these conditions with feature flags. Here I decided against introducing another feature flag because conditions are already complex enough and we don't indent to flip switches here. Incidents and Service Desk issues should just use the legacy views no matter the feature flags and settings.

Functionality overview

New route
1. Legacy view: We reuse the legacy view and
  1. Option a) (current POC behavior) remove the option to change the type from incident to something else (for example if you select new incident from the incidents list page).
  2. Option b) remove the type select altogether and use new incident language throughout the view.
2. Work items view: If you select the type Incident we’ll redirect you to the legacy view with only the incident type option.
Links from list view (full reload instead of router)
1. We determine whether we use the router to load the detail view or browse to the detail view for the legacy view.
2. This now includes a type condition so links to incidents and Service Desk issues will always browse to the legacy view.
Detail view
1. Depending on the user preference we render a different haml file and run different javascript. The logic now includes the type condition mentioned above, so when you access an incident or Service Desk issue directly it will always render the legacy view.
Work items feedback badge. The badge doesn’t render on
1. Legacy incidents view
2. Legacy Service Desk issues view
3. Legacy new view

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

I'll break this down into sections for each view and workflow:

New workflow

From issues list

With new issue look = off:

Before	After
Screen_Recording_2024-12-05_at_15.35.20	No change 👍

With new issue look = on:

❗ With user preference enabled (without work items alpha and beta FFs enabled) there's no option to add something different than an issue or objective right now (using the modal:

Screen_Recording_2024-12-06_at_15.14.02

Using work_items/new route (with access to legacy detail view):

Before	After
Screen_Recording_2024-12-06_at_15.50.12	Screen_Recording_2024-12-05_at_17.52.58

From incidents list

With new issue look = off:

Before	After
Screen_Recording_2024-12-06_at_15.36.53	No change 👍

With new issue look = on:

Before	After
❗ contains a bug today. You're not able to create an incident from here. Screen_Recording_2024-12-06_at_15.52.42	Screen_Recording_2024-12-05_at_17.55.37

From boards

No change (right now it's only possible to create issues from boards) 👍

List

With new issue look = off:

Before	After
Screen_Recording_2024-12-06_at_15.39.35	No change 👍

With new issue look = on:

Before	After
Screen_Recording_2024-12-06_at_15.57.48	Screen_Recording_2024-12-05_at_17.59.05

Detail

With new issue look = off:

Before	After
Screen_Recording_2024-12-06_at_15.41.11	No change 👍

With new issue look = on:

Before	After
Screen_Recording_2024-12-06_at_15.59.00	Screen_Recording_2024-12-06_at_15.45.40

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

This step by step guide walks you through all changed and unchanged workflows:

Preparation

In order to test everything we need to create a few records and make it easy for you to toggle the user setting (even if it's not visible in the UI). Run these commands in the ruby console using bundle exec rails c or bin/rails c (for best experience keep the console open so you don't need to refetch objects):

Find your user, access user preferences and print the current setting

user = User.find_by(username: 'root') # Adjust to your local username. Root is id 1
pref = user.user_preference

pref.use_work_items_view

Toggle user preference. Use these commands to change the user preference to your needs from the console. Let's start by setting it to false.
```
pref.update!(use_work_items_view: true)
pref.update!(use_work_items_view: false)
```

Select a project (by default flightjs) and create a Service Desk issue and an incident. Note that incidents are already work items under the hood but use legacy list and show views.

project = Project.find(7) # Or select another project. Get the id from the project general settings page

::Issues::CreateService.new(
  container: project,
  current_user: Users::Internal.support_bot,
  params: {
    title: 'Service Desk issue',
    description: 'Easy to spot Service Desk issue',
    confidential: true,
    external_author: 'user@example.com'
  },
  perform_spam_check: false
).execute

::WorkItems::CreateService.new(
  container: project,
  current_user: user,
  params: {
    title: 'Incident',
    description: 'Easy to spot Incident',
    work_item_type: ::WorkItems::Type.find_by(base_type: 1) # incident
  },
  widget_params: {}
).execute