Skip to content

Add display name description when Service Desk is not enabled

Ben King requested to merge benjaminking-servicedesk-settings into master

What does this MR do and why?

Currently, when Incoming Email (incoming_email) has been enabled, but not Service Desk (service_desk_email), some settings are displayed under a Project in Settings > General > Service Desk.

One option, "Email display name" shows only the label, with the text form and description text not shown if Service Desk has not been enabled in GitLab configuration. In its current state, this can cause confusion for some customers, as they want to use the feature but don't know that Service Desk must be enabled as well.

This MR replicates the same wording as the "Email address suffix" section on the same settings page, directing a user to set up Service Desk if they want to utilise this feature.

Screenshots or screen recordings

Both Before and After are shown with incoming_email setting enabled set to true, but service_desk_email enabled set to false.

Before MR After MR
image image

When Service Desk has been enabled, (service_desk_email set to true) the view is updated to:

image

How to set up and validate locally

  1. Deploy a Development instance of GitLab on the associated branch (benjaminking-servicedesk-settings)
  2. Navigate and open config/gitlab.yml. Under incoming_email set enabled: to true.
  3. Restart the development instance services.
  4. Navigate to any open project, then select Settings > General.
  5. Scroll-down to Service Desk. Because incoming_email is enabled, but not service_desk, the helpful description will be displayed.

Similarly, to test the behaviour with Service Desk enabled:

    1. Navigate and open config/gitlab.yml again. Under service_desk_email set enabled: to true.
  2. Restart the development instance services.
  3. If on the same settings page, perform a reload of the page, or otherwise navigate back to the same same Settings location.
  4. Notice with Service Desk enabled, the value is definable as intended.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports