feat: Add new report, and alert type: webhook
SUMMARY
I add webhook as a new selectable report type.
By the use of webhook the user can post csv/png/pdf to any endpoint, with some informative parameters as:
- name of the report
- id of the report
- report type (chart, or dashboard)
- content id
- content format
For security reasons I made a new optional parameter: WEBHOOK_SECRET. It's a secret string between the Superset and the webhook endpoint. In the case where WEBHOOK_SECRET is filled, Superset adds an "X-Webhook-Signature" parameter to the header of the post call, which hashes the json data to be sent. The receiving party can verify that the party sending the webhook is the real sender by hashing the received json data and comparing it with the sending party's "X-Webhook-Signature" parameter. If the two parameters do not match, the receiving party may reject the call because the sender is not the supposed host.
On the report log, we can get feedback about the successful, and not successful requests as well.
I'm happy to share my code with you guys!
TESTING INSTRUCTIONS
- (optional) Fill the WEBHOOK_SECRET input parameter in the config file
- On the Alerts & reports page, press the "+ Report" or "+ Alert" button.
- On the notification panel, you can select Webhook as Notification method
- Fill the webhook endpoint url
- Fill all the mandatory input
By the result you will get the selectend chart/dashboard file on your webhook endpoint with some informative parameters as:
- name of the report
- id of the report
- report type (chart, or dashboard)
- content id
- content format
ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [x] 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
- [x] Introduces new feature or API
- [ ] Removes existing feature or API
Codecov Report
:x: Patch coverage is 50.00000% with 35 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 70.69%. Comparing base (76d897e) to head (fee03d7).
:warning: Report is 2192 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #30044 +/- ##
===========================================
+ Coverage 60.48% 70.69% +10.20%
===========================================
Files 1931 2002 +71
Lines 76236 80869 +4633
Branches 8568 9148 +580
===========================================
+ Hits 46114 57172 +11058
+ Misses 28017 21476 -6541
- Partials 2105 2221 +116
| Flag | Coverage Δ | |
|---|---|---|
| hive | ∅ <51.92%> (∅) |
|
| mysql | ∅ <51.92%> (?) |
|
| postgres | ∅ <51.92%> (?) |
|
| presto | ∅ <51.92%> (∅) |
|
| python | ∅ <51.92%> (∅) |
|
| sqlite | ∅ <51.92%> (?) |
|
| unit | ∅ <51.92%> (∅) |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
Really cool idea @kistoth90!
I love the idea here. Approving the next CI run... ping me if it needs to be kicked again.
At this point I don't know what, or how should I fix the errors:
- I tried to run the cypress on my desk (cypress-run-chrome) but I got constant "400 Bad Request: The CSRF token is missing." during the login call. I was able to log in manually by the test credentials.
- the pre-commit works locally fine... i dont know why it want to refresh the source code during the CI run.
I would appreciate some assistance about, becauseI'm stuck.
For the Pre-commit issue, have you tried running ruff and black locally to remove the formatting blocks?
Hi @fisjac,
Yepp, the ruff, and Blacklist passed as well!
I made some changes by the guidance of dpgaspar. Let's hope the best! 🤞
Closing and reopening to try to get tests to kick off.
Hi @dpgaspar / @eschutho are there any blockers preventing merging this?
It closes https://github.com/apache/superset/issues/30304
/testenv up FEATURE_ALERT_REPORTS=true
@eschutho Processing your ephemeral environment request here.
It sounds like this feature may be a good use-case for putting behind a feature flag. I can see that some superset administrators may not want to enable webhooks to their users, even if they have the alerts/reports feature on.
Any update on this? This feature will be highly appreciated.
@kistoth90 would be great if this can be merged, really looking forward to this feature 🚀
@kistoth90 @eschutho @sadpandajoe A gentle ping regarding this.
@kistoth90 hi,is your code suitable for Superset version 4.1.0?
Hey @kistoth90 - any chance of getting this rebased so we can help get it across the finish line? I was just asked on Superset Slack if this feature exists, and it sure would be cool if it did! :)
Hello @dpgaspar , @eschutho , @rusackas, and @sadpandajoe,
I hope you’re well! Just kindly checking if there’s any update on merging this webhook PR. It looks like a great addition and would be much appreciated.
Currently the PR needs a rebase, and needs a response to the comments/change requests made by @eschutho. I'm equally excited to see this merged, so I hope it happens!
I would love to see the options for a webhook be configurable in the UI, if there's a secure way to do it... maybe treat it like a password, so it doesn't appear in the UI? Then users could add multiple webhook configs without having to bother an admin or restarting the service.
I'll be waiting
@kistoth90 can you rebase this PR? I think we're all pretty excited to see it merge :D