Skip to content

Adds state machine to Service Desk Custom Email Verification

Marc Saleiko requested to merge ms-service-desk-custom-email-verification-state-machine into master

Feature context

Click to expand 👇

Right now it is not possible to customize the Service Desk email address (intake and sending) in its entirety. On self-hosted instances you have more control over the used addresses, but you will still have a rather cryptic target email address for a specific service desk in a project. For .com users it's currently not possible to customize the Service Desk email at all.

There is a proposal and a further exploration around this issue. A summary of the solution path is the following: Users set up their custom email to forward all emails to the cryptic Service Desk email and provide SMTP credentials so we can send emails on their behalf. This way customers seeking support will only see the custom email address in their communication.

There is further discussion about improving and changing the general infrastructure, but this approach is a MVC to solve the issue for our customers.

🗺 How does it contribute to the whole feature?

Click to expand 👇

This MR is the second part in a series of MRs that will follow in order to complete this feature. See #329990 (comment 1227384943) for a detailed breakdown. Here's a summary:

  1. ✅ Using SMTP credentials. Foundation work.
  2. 🎯 Verify email ownership, correct function and setup Adds state machine to Service Desk Custom Email Verification
  3. Ingest replies from custom email
  4. Add settings and validation to Settings page
  5. Add documentation

What does this MR do and why?

🎏 The feature as a whole is hidden behind the feature flag service_desk_custom_email and is not enabled on production yet

This MR adds a state machine to ServiceDesk::CustomEmailVerification to ensure we follow the verification process.

  1. Start verification an move to running. This generates a verification token and records the start time. We will set the user that triggered the verification up front
  2. An error occurred and we move to error and provide the error type up front.
  3. The verification was successful and we move to verified and remove the verification token.

Screenshots or screen recordings

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

🚫

How to set up and validate locally

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

🚫

MR acceptance checklist

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

Edited by Marc Saleiko

Merge request reports