Reports (scheduled delivery of Charts and Dashboards outside of Preset)

[benceorlai]

Motivation / Problem to Solve

There are cases when a user wants to revisit a Chart or Dashboard regularly outside of Superset. These cases include wanting to:

• have the Chart/Dashboard sent to them regularly (e.g. every Monday morning) without having to remember it - for example for before a regular meeting
• see the Chart/Dashboard without having to log into Superset - for example to see it offline, or in a communication channel
• create a snapshot (static copy) of the Chart/Dashboard - for example save copies locally for research
• send a copy of the Chart/Dashboard to someone who has no access to Superset - for example send it to a customer

Superset has existing functionality to provide a solution for these use cases, but these features need improvements to better serve a larger user base.

Proposed solution

The existing Superset functionality uses two user flows in the UI:

• Dashboard Emails - to schedule reports for Dashboards
• Chart Email Schedules - to schedule reports for Charts

Take a phased approach to improving the functionality:

Phase 1

• Deprecate the current FAB view based CRUD UI for Dashboard Emails
• Deprecate the current FAB view based CRUD UI for Chart Email Schedules
• Build a new React based UI that unifies the two user CRUD flows
• Apply UX/UI improvements to the user flow

Phase 2

• Redesign the Reports UX/UI to move from a CRUD based approach to a task-based approach

[zuzana-vej]

This is great.

Another (related) use case we hear about from users is sending result of a sql query in csv file on a scheduled basis. There are users who can get chart from Superset, but there are users who need to format the data differently, in a way which current visualizations (e.g. esp. table viz) doesn't allow, or they just need to use it in Google sheet for other reasons.

They would like to:

1. write SQL query in SQL Lab
2. schedule that query - e.g. run this every monday at 9am
3. receive CSV where 1st tab will be the result and 2nd tab will be the actual SQL query which was used to generate that data

[benceorlai]

Thanks @zuzana-vej !

This use case makes complete sense. The way I think about reports is that there are three major components:

1. Data source: this can be data (saved query, chart query) or visualization (chart or dashboard)
2. Delivery channel: email, slack, webhook, etc.
3. Content: this can be a backlink to Superset or an actual snapshot attached to the notification (screenshot, pdf or data file). Google Sheets is an interesting hybrid case, but I can see how that format would be super useful for those who are in the Google Docs/Drive ecosystem.

I think if the users have these building blocks it allows for a lot of permutations and then everyone can build what they need

A couple of questions:

• what security concerns are you aware of around sending data outside of Superset?
• what is the users expectations for attachments (eg CSV file) that are large? Most email systems still keep attachment sizes below 20MB I think, what would users' expectations be if the attachment is larger than that?

[zuzana-vej]

Exciting! I think the components etc. makes a lot of sense.

To your questions:

• what security concerns are you aware of around sending data outside of Superset?
  --> Currently, the "email dashboard" solution checks the permissions of the person who set that up. Not the recipient. I would expect anyone who is recipient of the data have to be Superset user, and the permissions to receive the dashboard or report or any data needs to be based on the recipient, so every time before the email is send (just like as when user is accessing dashboard) it checks if they have permissions to view the data. This also means that user can't really setup to send out to email addresses outside the organization (since the user needs to exist in Superset). I think it's OK that anyone can schedule any chart/dashboard for anyone, but if there is a concern (that someone might schedule something being send to people who don't care about it), it can be limited to: owner can schedule to send to anyone; anyone can schedule to send to themselves.

• what is the users expectations for attachments (eg CSV file) that are large? Most email systems still keep attachment sizes below 20MB I think, what would users' expectations be if the attachment is larger than that?
  --> great point, I think there definitely should be limit. I would expect people to use it for reports so couple tens, hundreds lines in CSV. Not to run bulk queries. So I think as phase 1, not sending larger size than X MB can be OK. And phase 2 i can imagine user receives a link and upon clicking on the link, they can download the result.

Another feature on this is when a report is being emailed as CSV, some users requested they would like to see the SQL which generated the CSV, either in the report, or be able to have a link and view the SQL.

[zuzana-vej]

Another use case which can be addressed in future phases is around readability of charts. Most charts are meant for interactive exploration, and don't have values on the chart. For example line chart showing trends over time, as user hovers over, they can read the actual values. If this chart is emailed as a screenshot - user can see the trend, but doesn't really see the values.

[MacNale]

If the dashboard has filter box, then will this functionality allow me to configure which filter values will be used while scheduling the report?