feat(reports): allowing the email mutator to update recipients

[SkinnyPigeon]

SUMMARY

We use the EMAIL_HEADER_MUTATOR to detect errors in reports sent to our external clients. Currently, when an error is detected we send an alert to an internal Slack channel and replace the contents of the notification with a generic message saying There has been an issue generating your report.... However, our account managers have asked us not to send the report. Unfortunately, there is no way to prevent the reports from being sent beyond causing an Exception to be raised, which causes issues.

This PR allows users to use msg.replace_header("To", <superset_admin/empty_string>) as part of the EMAIL_HEADER_MUTATOR in the config to replace the list of recipients. We plan to either replace the recipients with an empty string or send it to an internal email so we are notified of the results.

I opened an Idea previously for this but it has not been picked up.

TESTING INSTRUCTIONS

I have added an additional unit test in the relevant section of the tests repo. Additionally, in your local setup you can add the following to your superset_config.py

def EMAIL_HEADER_MUTATOR(msg, **kwargs):
  msg.replace_header("To", "[email protected]")
  return msg

ADDITIONAL INFORMATION

• [x] Has associated issue:
• [ ] Required feature flags:
• [ ] Changes UI
• [ ] Includes DB Migration (follow approval process in SIP-59)
  • [ ] Migration is atomic, supports rollback & is backwards-compatible
  • [ ] Confirm DB migration upgrade and downgrade tested
  • [ ] Runtime estimates and downtime expectations provided
• [ ] Introduces new feature or API
• [ ] Removes existing feature or API

[SkinnyPigeon]

I've updated the code to pass the failing tests, I was unable to get my testing environment working correctly yesterday

[sfirke]

Going to close and open to re-trigger CI

[sfirke]

@john-bodley this is now passing CI and has a response to your comment. The author writes today in Slack:

This would unblock a major issue that our account managers have with a minimally disruptive change. There is definitely scope for a larger change to how the EMAIL_HEADER_MUTATOR works, however, that would likely be a breaking change so this would be a nice step in the right direction without introducing that

[SkinnyPigeon]

Hey folks, can we look at this and decide one way or another, please?