Report Schedule Dashboard Integration#

A ReportSchedule can target either a chart or a dashboard. When targeting a dashboard, the optional extra.dashboard field carries a DashboardPermalinkState snapshot — native filter values, active tabs, URL parameters, and an anchor — that the execution engine uses to render the dashboard in a specific state before screenshotting it.

This behavior is gated by the ALERT_REPORT_TABS feature flag 1. Without the flag, the report always renders the full dashboard at its default state.

The extra.dashboard Field#

ReportSchedule.extra_json stores a ReportScheduleExtra TypedDict with a single key dashboard of type DashboardPermalinkState:

The extra field is declared as a plain fields.Dict in both ReportSchedulePostSchema and ReportSchedulePutSchema — structure enforcement happens in the command layer, not the schema layer.

Permalink State Creation at Execution#

When a dashboard report executes, BaseReportState._get_url() decides whether to use a stateful permalink or a plain dashboard URL:

1. If extra.dashboard is set and ALERT_REPORT_TABS is enabled, it calls _get_tab_url(dashboard_state).
2. Otherwise, it falls back to a plain Superset.dashboard URL using the dashboard's UUID 2.

_get_tab_url() invokes CreateDashboardPermalinkCommand with the dashboard's UUID and the full DashboardPermalinkState, stores the state in the key-value store, and returns the /superset/dashboard/p/<key>/ permalink URL 3. The webdriver then loads this URL and the frontend restores all filter and tab state before taking the screenshot.

Multi-tab screenshots: When anchor is a JSON-encoded list of tab IDs, _get_tabs_urls() generates a separate permalink per tab — one screenshot per tab. Each per-tab permalink is constructed with dataMask, activeTabs, and urlParams all set to None, only the anchor varies 4.

get_dashboard_urls() is the entry point for _get_screenshots() when the report targets a dashboard 5.

extra.dashboard set + ALERT_REPORT_TABS enabled
  └─ anchor is JSON list? → _get_tabs_urls() → one permalink per tab
  └─ otherwise → _get_tab_url() → single permalink
extra.dashboard absent OR flag disabled
  └─ plain dashboard URL (no permalink created)

Validation on Create and Update#

Tab/anchor validation — CreateReportScheduleCommand._validate_report_extra() checks that every ID in activeTabs and anchor exists as a key in the dashboard's position_json. A JSON-encoded anchor list is parsed and each entry validated individually; a plain string anchor is checked directly against position_data 6. Invalid IDs produce a 422 ValidationError on the extra field.

Native filter validation — PR #38715 added _validate_native_filters() to the base command, enforcing that each object in extra.dashboard.nativeFilters:

• Contains all required keys: nativeFilterId, filterType, columnName, filterValues
• Has filterValues as a list
• References a nativeFilterId that actually exists on the target dashboard

Previously, arbitrary native filter data was accepted at creation time and only failed at execution 7. The same PR moved _validate_report_extra() to BaseReportScheduleCommand so these checks run on both create and update.

Automatic Report Deactivation on Dashboard Changes#

UpdateDashboardCommand proactively deactivates reports when the dashboard elements they reference are removed.

Tab deletion — process_tab_diff() compares the new position_json against the current tab configuration, finds reports referencing deleted tab IDs via ReportScheduleDAO.find_by_extra_metadata(tab), sets each report to active=False, and sends a deactivation email to all report owners 7.

Native filter deletion — Added in PR #38715, process_native_filter_diff() diffs json_metadata.native_filter_configuration before and after the update to detect removed filter IDs. Affected reports are found via ReportScheduleDAO.find_by_native_filter_id() (which searches extra_json for the filter ID with SQL LIKE and autoescape=True), then deactivated and owners notified via _send_deactivated_report_email() — a shared helper reused for both tab and filter deactivation flows 7.

Key Files#