WIP: Resolve "Spike: Email Integration for Alerts"
What does this MR do?
This MR implements a quick and dirty Email integration for Alert Management, hence the word "Spike" (see #217178 (closed)). It can inspire future implementations for #214525 (closed).
Implementation details + questions
- A new email handler (
Gitlab::AlertManagement::IncomingEmail::CreateAlertHandler
) (see https://docs.gitlab.com/ee/development/emails.html#incoming-email for more context)-
❔ Leave it namespaced or move toGitlab::Email::Handler::CreateAlertHandler
-
❔ Improve error handling (currently justInvalidRecordError
with message from service)?- If "Alerts integration" processing an email is a noop - see TODO
-
❔ Should we allow GitLab Flavored Markdown?
-
- Mail handler uses a short version of the token from "Alerts integration" -
-
❔ "Option 2" from #214525 (comment 354720971)
-
- The email handler calls
Projects::Alerting::NotifyService
passing email subject and body-
❔ Use email date asstarts_at
-
❔ Support monitortool specific email templates
-
- Mail handler includes
ReplyProcessing
-
❔ Alert Bot
was chosen asauthor
. OK? -
❔ Check the "quick action" abilities with this module
-
- Just one happy path spec
-
❕ Add more!
-
- Alerts integration is incomplete
-
❕ Passincoming_email_address
to frontend and add acopy
button -
❕ Addincoming_email_address
to API soReset token
also updates the "Email address" -
❔ Edge cases when inactive/fresh
-
-
docs-missing
- User documentation
- Dev documentation
Screenshots
Alerts integration | Mail client | Alert details | Incident issue |
---|---|---|---|
Try it
- Checkout this branch
- Configure "Incoming email" as described in user docs or dev docs
- Start GDK
- Start mail_room
- Create a project and enable Settings > Integrations > Alerts endpoint
- Use the
Email address
from the settings page to send a test mail - Watch GitLab creating an Alert (
"Category:Alert Management") and Incident Issue ("Category:Incident Management") 🎉
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Edited by Rémy Coutable