Moves Service Desk custom email credentials to own table
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 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:
-
✅ Using SMTP credentials. Foundation work. Add Service Desk custom email foundation (!108017 - merged) -
🎯 Verify email ownership, correct function and setup Part 2: Move credentials to own table to address additional access methods - Ingest replies from custom email
- Add settings and validation to Settings page
- Add documentation
What does this MR do and why?
With the rise of the draft to move email ingestion to sidekiq worker jobs and my recent interviews with customers that request direct email ingestion of their mailboxes, I want to make the architecture a bit more scalable before we get into beta testing once the first iteration "customizable email addresses using email forwarding and sending via SMTP" is done. As we will probably see more fields like imap_address and oauth_access_token or oauth_refresh_token, I'd like to move all these credentials to a dedicated table, because we only need these fields when we send emails and not everytime we access ServiceDeskSetting. We already added custom email verification fields to a dedicated table with project_id as the PK.
The diagrams below illustrate the model and database changes.
I'd recommend to review the files in the side-by-side view, so it's easier to see how things were moved without all the "git noise".
Before
After
Screenshots or screen recordings
No screenshots.
How to set up and validate locally
No special steps here, as only database migrations and model methods are involved.
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.