feat(alerting): Make email alert provider e-mail customizable #1119
Conversation
alerting/provider/email/email.go
Outdated
| subject = fmt.Sprintf("[%s] Alert resolved", ep.DisplayName()) | ||
| message = fmt.Sprintf("An alert for %s has been resolved after passing successfully %d time(s) in a row", ep.DisplayName(), alert.SuccessThreshold) | ||
| if len(cfg.TextEmailSubjectResolved) > 0 { | ||
| subject = strings.Replace(cfg.TextEmailSubjectResolved, "{endpoint}", ep.DisplayName(), 1) |
There was a problem hiding this comment.
If we're going to implement placeholders, they should be the same as the other placeholders throughout the configuration. See https://github.com/TwiN/gatus?tab=readme-ov-file#configuring-custom-alerts
[ENDPOINT_NAME] (resolved from endpoints[].name)
There was a problem hiding this comment.
Hello! I've used {endpoint} and {description} placeholders i the Twilio provider, too. Should I unify them?
#1120
alerting/provider/email/email.go
Outdated
| TextEmailSubjectTriggered string `yaml:"text-email-subject-triggered,omitempty"` | ||
| TextEmailSubjectResolved string `yaml:"text-email-subject-resolved,omitempty"` | ||
| TextEmailBodyTriggered string `yaml:"text-email-body-triggered,omitempty"` | ||
| TextEmailBodyResolved string `yaml:"text-email-body-resolved,omitempty"` | ||
| TextEmailHeader string `yaml:"text-email-header,omitempty"` | ||
| TextEmailFooter string `yaml:"text-email-footer,omitempty"` | ||
| TextEmailDescription string `yaml:"text-email-description,omitempty"` | ||
| TextIncludeConditionResults *bool `yaml:"text-include-condition-results,omitempty"` |
There was a problem hiding this comment.
I'm really not sure about this. I'd almost rather have just the subject and the body, and then have a placeholder for the condition results. This would remove the need for the header, the footer, the description and the bool to include/exclude the condition results.
There was a problem hiding this comment.
Hello! I would like to be able to say hello and display information in the footer in the case of an email alert provider, all fields as optional parameter. And everything is backward compatible. Given that not everyone understands the technical details, I would like to optionally hide the condition results section.
There was a problem hiding this comment.
I'm really not sure about this. I'd almost rather have just the subject and the body, and then have a placeholder for the condition results. This would remove the need for the header, the footer, the description and the bool to include/exclude the condition results.
Sorry, I just understood exactly what you wanted. I'll edit it and report back with the changes.
|
Hello @TwiN ! I've updated the code as you requested: imrelaszlo@324d2cd |
TwiN
changed the title
Yes, but please be patient, I found a bug and am making a better version, which I will submit as a separate pull request. |
|
@imrelaszlo Should I close this in favor of #1129? |
Yes, the other solution is much nicer, more capable and more modern. |
Summary
Now, we can override e-mail messages texts via provider-override settings, like this:
All fields are optional, and backwards compatible. You can hide the condition results if needed.
Checklist
README.md, if applicable.