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", "fake@email.com")
  return msg

ADDITIONAL INFORMATION

• 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

[github-actions]

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

[john-bodley]

I'm not certain whether this should be handled here for the specific bespoke use case or we should change the EMAIL_HEADER_MUTATOR (or similar) to return recipients as well.

[SkinnyPigeon]

Hey @john-bodley, thanks for taking a look. Ideally we'd love to have control over the actual email object including the dry_run flag but I thought this would be a simple step in that direction that would suit our immediate needs.

Changing the return values for this would probably cause a bit of a headache for many existing users. How would you suggest we continue?

[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?

[SkinnyPigeon]

Can we have a review for this, please? We would love this to be implemented or at least a proper alternative proposed. Being able to remove recipients from reports or prevent the reports being sent on the detection of errors would really improve the experience of our clients

[rusackas]

I'm pinging the current reviewers (@eschutho and @john-bodley) here and over on slack to either take another look or pass the buck :) Thanks for the comment, and thanks for your patience.

[SkinnyPigeon]

I'm pinging the current reviewers (@eschutho and @john-bodley) here and over on slack to either take another look or pass the buck :) Thanks for the comment, and thanks for your patience.

Thanks very much for your help throughout. I'd just love to give an update to our account managers about the future of this, even if we have to do a more comprehensive PR to address the concerns of @john-bodley

[john-bodley]

@betodealmeida, @dpgaspar, @villebro et al. I would love your input/thoughts here. I guess the caveats (potentially non-blocking) I see is that:

1. There's no longer transparency in terms of who could potentially receive the email.
2. Potentially new security/access controls concerns.

[SkinnyPigeon]

Thanks @john-bodley for taking another look

[eschutho]

Hi @SkinnyPigeon is the use case that you want to change the recipients only when there is an error? I'm thinking like here?

[SkinnyPigeon]

Hi @eschutho! Yes, we would like to replace or remove the recipients on error detection. A major concern for me, however, is that Superset does not currently register all errors as errors during report creation.

For instance, if the source table for a dataset is deleted this produces an orange error message box when the query is run for the report. Alternatively, a red error message box is shown if a query takes too long. Superset does not class these as errors and happily takes the screenshot and sends the report. We use the mutator to detect these error boxes and replace the report with a generic message saying there was an issue generating the report and to contact their account manager. We work with our report creators themselves to minimise these errors, but these are the realities of working with a self-serve ethos.

As such, I am worried that moving the error handling over there will not solve our issue unless we have some control over flagging the report as containing errors and thus ensuring that this method is called

[eschutho]

Thanks @SkinnyPigeon, this sounds like a good solution for now. Appreciate the contribution!

[SkinnyPigeon]

Thanks so much, folks! That's going to be massive for our account managers