Adds Service Desk settings custom email form component
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?
This MR is part of 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:
-
✅ Using SMTP credentials. Foundation work. -
✅ Verify email ownership, correct function and setup -
🎯 Add settings and validation to Settings page.- Backend
-
✅ Create and Destroy Services -
✅ CustomEmailController
-
- Frontend
-
✅ CustomEmail component foundation with initial resource fetching - merge request dependency -
🎯 CustomEmailForm component with resource saving -
🚫 CustomEmailStateStarted and CustomEmailConfirmModal components (with resource deletion) -
🚫 CustomEmailStateFailed component (with resource deletion) -
🚫 CustomEmailStateFinished component with resource update
-
- Backend
- Ingest replies from custom email
-
👷🏻 Add documentation
What does this MR do and why?
and this MR targets the dependency's branch to clean up diffs. Once !126532 (merged) has been merged, I'll rebase this MR on the current master. Rebased on master.
This MR adds the CustomEmailForm
component to the CustomEmail
component. The CustomEmailForm
component will be rendered when no custom email has been set up yet. So the user needs to provide the SMTP data and set up email forwarding. On submit, the CustomEmailForm
component emits a submit
event with the form data. The CustomEmail
component takes that event and sends the create request to the backend and displays a toast on success and an alert on failure. The form should disappear. The next MR will add the next screen (verification state started).
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
Resource fetched, no custom email configured yet --> show form:
All fields with validation errors:
All fields filled out, button enabled:
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
-
Turn on (at least)
incoming_email
in yourgitlab.yml
. -
Enable
service_desk_custom_email
feature flag🎏 , e.g. forFlight
project:Feature.enable(:service_desk_custom_email, Project.find(7)) # or your project id
-
Browse to
http://127.0.0.1:3000/flightjs/Flight/edit
and expand theService Desk
section and find the custom email card below the general settings. -
Fill in the fields and see that the save button is only enabled with valid input data. Also see validation messages on error.
-
Open the network tab of the dev tools and hit the send button. You should see a
POST
request to the backend with your input. The response should contain some of your input data and a toast should display that the custom email was saved. -
You should see a warning alert on error (network or logic).
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.