feat: add date format to the email subject

[US579]

SUMMARY

Problem
If the subject remains the same, all scheduled reports will be delivered in the same email thread, requiring the recipient to scroll back to the original thread to find the latest email.

However, if a date is included in the email subject, the emails will not be grouped in the same thread. To address this, I propose adding a feature that allows users to specify a date format in the email subject, enabling the email client to correctly thread the emails and display them in a more organized manner.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before

After

How to use it

Set the DATE_FORMAT_IN_EMAIL_SUBJECT=True to allow users to include a date format in the email subject, which will automatically be replaced with the corresponding actual date.

available date format https://strftime.org/

Example

In this example i defined Year-Day-Minutes

Year - %Y
Day - %D
Minutes - %M

Output

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags: DATE_FORMAT_IN_EMAIL_SUBJECT (by default is disabled)
• 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

[codecov]

Codecov Report

Attention: Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.

Project coverage is 83.77%. Comparing base (d5a4815) to head (224e281).

Files with missing lines	Patch %	Lines
superset/reports/notifications/email.py	90.90%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #31413       +/-   ##
===========================================
+ Coverage        0   83.77%   +83.77%     
===========================================
  Files           0      538      +538     
  Lines           0    39153    +39153     
===========================================
+ Hits            0    32801    +32801     
- Misses          0     6352     +6352     

Flag	Coverage Δ
hive	48.76% <63.63%> (?)
mysql	76.48% <81.81%> (?)
postgres	76.56% <81.81%> (?)
presto	53.27% <63.63%> (?)
python	83.77% <90.90%> (?)
sqlite	76.02% <81.81%> (?)
unit	60.91% <81.81%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sadpandajoe]

Can you mention this new feature flag in UPDATING.md

[US579]

thanks for reviewing! i have updated

[sadpandajoe]

@US579 can you also add some documentation on how this is used? It won't be clear for users who don't know about this feature that they can start doing this post merge.

[rusackas]

The flag should also be documented/categorized in FEATURE_FLAGS.md

[US579]

@US579 can you also add some documentation on how this is used? It won't be clear for users who don't know about this feature that they can start doing this post merge.

hey @sadpandajoe Could you point me where is the bast place to add this doc, currently i just added here

[sadpandajoe]

@US579 can you also add some documentation on how this is used? It won't be clear for users who don't know about this feature that they can start doing this post merge.

hey @sadpandajoe Could you point me where is the bast place to add this doc, currently i just added here

@US579 great question. I would say you can either put it in the alerts and reports sections: https://github.com/apache/superset/blob/4ff9aac1fae2d88fd7667317c706256d3cfcb4f4/docs/docs/configuration/alerts-reports.mdx or in the faq https://github.com/apache/superset/blob/4ff9aac1fae2d88fd7667317c706256d3cfcb4f4/docs/docs/faq.mdx

[rusackas]

It looks like this docs link and the one above it are swapped.

Also, it would nice to add a docs entry rather than linking to the PR. You can run the docs locally and just add some markdown. Docs on how to do that are here.

[US579]

thanks for pointing me to the right direction! i have added an entry and updated the link

[mistercrunch]

Totally get the use case. Hey I'm wondering if it may make sense to support more templating in emails (subject and body) in general to tackle this use case but similar ones as well. I know jinja isn't safe for untrusted (user-provided) content, maybe we could use some pybars or something untrusted safe to allow for bringing arbitrary context in arbitrary places in the subject/body.