Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Customizable email subject name #26327

Merged
merged 55 commits into from
May 16, 2024

Conversation

puridach-w
Copy link
Contributor

SUMMARY

This feature allows users to customize the email subject when creating a report or an alert within Superset. This is driven by a need to include specific parameters within the email subject line, enhancing the specificity and resonance of alert or report notifications.

Changes:

  • Implementation of a new text input field within the 'create alert/report' interface, through which users can specify their desired email subject line.
  • If the text field is left blank, a default email subject line will be generated by the system.
  • The user interface will show the new text field solely when the email sending method is selected by a user.

This feature has been tested with Superset master branch.
This proposed feature has already been discussed in the Superset Improvement Proposal (see #25945)

BEFORE SCREENSHOTS

image

image

AFTER SCREENSHOTS

image

image

TESTING INSTRUCTIONS

To verify the changes made, please follow these steps: (Assume that there TAG for alert and report and open)

  • Go to the Alert and report creation page
  • Create one of them
  • Fill all the information that required
  • Select Notification method as "Email"
  • You will see input box for "email subject name"
  • Fill the desired subject name and save it
  • Wait for email send and check the email subject name

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

@puridach-w puridach-w requested a review from a team as a code owner December 21, 2023 05:50
@puridach-w
Copy link
Contributor Author

Run: superset db downgrade

Screenshot 2566-12-21 at 12 53 24

Run: superset db upgrade

Screenshot 2566-12-21 at 12 53 35

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -177,8 +177,7 @@ def _get_content(self) -> EmailContent:

def _get_subject(self) -> str:
return __(
"%(prefix)s %(title)s",
prefix=app.config["EMAIL_REPORTS_SUBJECT_PREFIX"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like this could still be useful even with per-schedule customisation, as you might want to prefix all your emails with a standard prefix and then choose individual subject lines after the prefix. I'd continue supporting it, though we could probably improve the behaviour where prefix is None or empty by removing any leading space etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if the user wants to have prefix then they can always add it themselves and we should allow user 100% control over their email subject.

For the default subject line it still have prefix I just modify code to this

if self._report_schedule.chart:
                name = (
                    f"{prefix} "
                    f"{self._report_schedule.name}: "
                    f"{self._report_schedule.chart.slice_name}"
                )
            else:
                name = (
                    f"{prefix} "
                    f"{self._report_schedule.name}: "
                    f"{self._report_schedule.dashboard.dashboard_title}"
                )

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @giftig on the premise that the app.config is set by the application admin, whereas the title will be set by individual users. If an application admin set an app.config prefix, it's likely something important that they don't want removed from the emails, such as "Company Confidential", etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I got it. I already modify to be as previous.

superset-frontend/src/features/alerts/AlertReportModal.tsx Outdated Show resolved Hide resolved
@giftig
Copy link
Contributor

giftig commented Dec 21, 2023

Thanks for contributing @puridach-w . I've added some minor suggestions and kicked off the build for you.

Copy link

codecov bot commented Dec 21, 2023

Codecov Report

Attention: Patch coverage is 68.75000% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 69.81%. Comparing base (b25dd0c) to head (c78a4d1).

Files Patch % Lines
...-frontend/src/features/alerts/AlertReportModal.tsx 61.11% 4 Missing and 3 partials ⚠️
.../features/alerts/components/NotificationMethod.tsx 60.00% 2 Missing ⚠️
superset/commands/report/execute.py 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master   #26327      +/-   ##
==========================================
- Coverage   69.81%   69.81%   -0.01%     
==========================================
  Files        1910     1910              
  Lines       74827    74856      +29     
  Branches     8346     8357      +11     
==========================================
+ Hits        52243    52263      +20     
- Misses      20532    20538       +6     
- Partials     2052     2055       +3     
Flag Coverage Δ
hive 48.99% <44.44%> (+<0.01%) ⬆️
javascript 57.39% <60.86%> (+<0.01%) ⬆️
mysql 77.98% <88.88%> (-0.03%) ⬇️
postgres 78.12% <88.88%> (+<0.01%) ⬆️
presto 53.72% <44.44%> (+<0.01%) ⬆️
python 83.14% <88.88%> (+<0.01%) ⬆️
sqlite 77.55% <88.88%> (+<0.01%) ⬆️
unit 56.72% <44.44%> (+<0.01%) ⬆️

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.

@puridach-w
Copy link
Contributor Author

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (8c32c6d) 69.18% compared to head (f7c7a9a) 59.04%.
Report is 5 commits behind head on master.

Files Patch % Lines
superset/commands/report/execute.py 0.00% 6 Missing ⚠️
Additional details and impacted files
☔ View full report in Codecov by Sentry. 📢 Have feedback on the report? Share it here.

What should I do with this? Can you suggest please.

@john-bodley
Copy link
Member

ping @eschutho and @lilykuang who are working on SIP-110.

@puridach-w puridach-w requested a review from giftig January 5, 2024 03:38
@puridach-w
Copy link
Contributor Author

@giftig @john-bodley Could you please help me review this PR again?

@giftig
Copy link
Contributor

giftig commented Jan 9, 2024

@puridach-w the code all looks ok to me but I'm not very familiar with the subject of reports. I think it'd be a good idea to get a review from @eschutho or @lilykuang since they're working on the related SIP John mentioned above; would be good to confirm what's done here aligns ok with that work.

@eschutho
Copy link
Member

eschutho commented Jan 9, 2024

@kasiazjc and @yousoph for design feedback, too.

@eschutho
Copy link
Member

eschutho commented Jan 9, 2024

/testenv up FEATURE_ALERT_REPORTS=true

Copy link
Contributor

github-actions bot commented Jan 9, 2024

@eschutho Ephemeral environment spinning up at http://34.222.243.175:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

superset/reports/models.py Outdated Show resolved Hide resolved
f"{self._report_schedule.name}: "
f"{self._report_schedule.dashboard.dashboard_title}"
)
name = self._report_schedule.email_subject
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name variable is really just for internal logs. I'm not sure if the subject line would help here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If i didn't misunderstand the code that use for send alert is smtp
send_email_smtp( to, subject, content.body, app.config, files=[], data=content.data, images=content.images, bcc="", mime_subtype="related", dryrun=False, header_data=content.header_data, )

and subject it come from this
def _get_subject(self) -> str: return __( "%(title)s", title=self._content.name, )

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing that out. You're correct. Maybe just a small nit for readability, I would switch the logic to

if self._report_schedule.email_subject:
    name = self._report_schedule.email_subject
else:
...
```
I also left a separate comment about persisting the app.config prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified


if (name === 'name') {
updateEmailSubject();
}
Copy link
Member

@eschutho eschutho Jan 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of using onInputChange here, you can just create a new event handler like this for example:

  const onSubjectChange = (value: string) => {
    updateEmailSubject(value);
  };

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it also needs to update the 'report name' value in the state before updating the email subject. That is the reason why I added this code. It is used to show the default subject line immediately when changing the report name. If a separate function is used, code must also be added to set the new value into the state, which will cause redundant code.

if (name === 'name') {
      updateEmailSubject();
    }

Copy link
Member

@eschutho eschutho Jan 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the pattern that the other fields are using, just to be consistent, is something like this:

const onSubjectChange = (value: string) => { 
        updateAlertState('email_subject', value); 
    };

That will add the subject key/val into currentAlert. I don't think you need to have both emailSubject in local and currentAlert.email_subject in the parent component state.

Copy link
Contributor Author

@puridach-w puridach-w Jan 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First video:
https://github.com/apache/superset/assets/76474644/47df84ce-e7c1-4db9-b008-3b43b6c39592

From the first video, it can be observed that the Report or Dashboard name changes whenever the _default value that's shown as a placeholder changes. The need for two variables arises from the requirement to display the default Subject name, and another one to store the customized name.

Second Video:
https://github.com/apache/superset/assets/76474644/bb024b5e-96e6-4323-ada7-cef981752341

As shown in the second video, initially when I customize the "Email subject name", it changes again when I edit the report name. This is caused by using only the currentAlert.subject_name as the placeholder and value for the "Email subject name" field. Therefore, when the report name is changed, the "Email subject name" field gets updated.

Do you think it's important to display the default email subject line?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eschutho would you kindly provide your opinion on this matter?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the videos. I'll defer to a product or design person on the functionality. @yousoph do you think the default subject line should appear in the email subject field?

Copy link
Member

@eschutho eschutho Feb 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delayed response here, but the rest is looking good to me. Thanks for all the contributions @puridach-w!

Copy link
Member

@eschutho eschutho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments. Feel free to ping me if you'd like any clarification on anything or have questions.

@puridach-w
Copy link
Contributor Author

Ping @eschutho I have already modified the code based on your comment.

@puridach-w
Copy link
Contributor Author

Ping @eschutho Could you please help me review this PR again?

setEmailSubject(
`${currentAlert?.name}: ${currentAlert?.dashboard?.label || ''}`,
);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since the default is handled in execute.py (server side) I don't think you need to also define it here in the client. It can just be left blank.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you can see in the image the default value will be shown if user doesn't input any text and this code is a part of that function.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the placeholder could show the default if empty? This would also allow for users to revert back to default if they've saved a report with a name, but want to return to the Superset default subject line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @eschutho @yousoph, What are your thoughts on reverting to displaying the default value in the placeholder? This way, users can easily revert to the default if they accidentally delete the email_subject. For example, if we make the "email_subject" field a required field and the user deletes it, it could be harder for them to restore the default value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me

@puridach-w
Copy link
Contributor Author

Ping @eschutho Could you please help me review this PR again?

@geido
Copy link
Member

geido commented Apr 29, 2024

/testenv up FEATURE_ALERT_REPORTS=true

Copy link
Contributor

@geido Ephemeral environment spinning up at http://52.34.171.63:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

@geido
Copy link
Member

geido commented May 2, 2024

@puridach-w not sure if this is related to your PR or not but I cannot add a report. It thinks recipients are not entered even though I did. Can you verify that, please?

@puridach-w
Copy link
Contributor Author

@puridach-w not sure if this is related to your PR or not but I cannot add a report. It thinks recipients are not entered even though I did. Can you verify that, please?

Sure let me check

@codecov-commenter
Copy link

codecov-commenter commented May 5, 2024

Codecov Report

Attention: Patch coverage is 56.52174% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 70.17%. Comparing base (76d897e) to head (8e37edf).
Report is 108 commits behind head on master.

Files Patch % Lines
...-frontend/src/features/alerts/AlertReportModal.tsx 56.52% 6 Missing and 4 partials ⚠️
.../features/alerts/components/NotificationMethod.tsx 35.71% 7 Missing and 2 partials ⚠️
superset/commands/report/execute.py 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master   #26327      +/-   ##
==========================================
+ Coverage   60.48%   70.17%   +9.68%     
==========================================
  Files        1931     1944      +13     
  Lines       76236    77327    +1091     
  Branches     8568     8668     +100     
==========================================
+ Hits        46114    54264    +8150     
+ Misses      28017    20938    -7079     
- Partials     2105     2125      +20     
Flag Coverage Δ
hive 49.10% <44.44%> (-0.07%) ⬇️
javascript 57.72% <48.64%> (+0.01%) ⬆️
mysql 77.10% <88.88%> (?)
postgres 77.23% <88.88%> (?)
presto 53.65% <44.44%> (-0.15%) ⬇️
python 83.41% <88.88%> (+19.92%) ⬆️
sqlite 76.68% <88.88%> (?)
unit 58.81% <44.44%> (+1.19%) ⬆️

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.

@puridach-w
Copy link
Contributor Author

Hi @geido , as I checked, I found that the issue come from the updateNotificationSetting function in the AlertReportModal file. The problem arises because the function does not update the state with the new setting value, resulting in the recipient variable doesn't have a value. I've fixed this by adding an else statement to update the setting value.

@geido
Copy link
Member

geido commented May 7, 2024

/testenv up FEATURE_ALERT_REPORTS=true

Copy link
Contributor

github-actions bot commented May 7, 2024

@geido Ephemeral environment spinning up at http://52.39.176.197:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

@geido
Copy link
Member

geido commented May 8, 2024

/testenv up FEATURE_ALERT_REPORTS=true

Copy link
Contributor

github-actions bot commented May 8, 2024

@geido Ephemeral environment spinning up at http://34.213.161.78:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

@geido
Copy link
Member

geido commented May 8, 2024

Hey @puridach-w this is looking much better now. However, I noticed that you can add an empty space as a valid value for the subject. Should we probably strip it or allow for a minimum amount of chars? Wdyt?

@puridach-w
Copy link
Contributor Author

Hey @puridach-w this is looking much better now. However, I noticed that you can add an empty space as a valid value for the subject. Should we probably strip it or allow for a minimum amount of chars? Wdyt?

Hi @geido. I agree and have added the condition to trap that case. Could you please review it again? There's a failed job under 'Build & Publish Docker Images / docker-build', but I noticed there is an open PR aimed at resolving the issue.

@geido
Copy link
Member

geido commented May 16, 2024

/testenv up FEATURE_ALERT_REPORTS=true

Copy link
Contributor

@geido Ephemeral environment spinning up at http://54.218.89.202:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

Copy link
Member

@geido geido left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the hard work on this!

@geido geido dismissed eschutho’s stale review May 16, 2024 13:04

Several iterations have been made on the PR and it looks ready now

@geido geido merged commit aa2b060 into apache:master May 16, 2024
36 checks passed
Copy link
Contributor

Ephemeral environment shutdown and build artifacts deleted.

EnxDev pushed a commit to EnxDev/superset that referenced this pull request May 31, 2024
Co-authored-by: Puridach Wutthihathaithamrong <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Related to the REST API risk:db-migration PRs that require a DB migration size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants