Scheduled report permalinks do not preserve dashboard dataMask state

[ayush-sharaf]

Bug description

Bug description

Scheduled dashboard reports can store dashboard state under ReportSchedule.extra.dashboard, including native filter state in dataMask.

During report generation, per-tab permalinks are created in superset/commands/report/execute.py. While building those tab-specific permalinks, the existing dashboard state from the report schedule is not preserved.
As a result, dataMask is dropped and scheduled report screenshots may ignore the filter state that was configured on the report schedule.

This is especially visible for scheduled reports that depend on native time filters. Even if the schedule stores the correct date filter state in extra.dashboard.dataMask, the generated permalink does not carry that
state forward, so the rendered report can show incorrect or unfiltered results.

How to reproduce the bug

1. Create a dashboard with multiple tabs.
2. Add native filters to the dashboard, including a time filter.
3. Create a report schedule for that dashboard.
4. Persist dashboard filter state in ReportSchedule.extra.dashboard.dataMask.
5. Enable ALERT_REPORT_TABS.
6. Run report generation for the scheduled dashboard.
7. Inspect the generated permalink state or the resulting screenshots.

Expected behavior

Scheduled report generation should preserve the parent dashboard state stored in ReportSchedule.extra.dashboard when building per-tab permalinks.

That includes preserving:

• dataMask
• activeTabs
• urlParams

As a result, generated screenshots should reflect the same native filter state stored on the report schedule.

Actual results

Per-tab permalink generation drops stored dashboard state, causing dataMask not to be respected during report execution.

Screenshots/recordings

N/A

Environment

• Superset version: current master
• Feature flag: ALERT_REPORT_TABS

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hi @ayush-sharaf! I'm Dosu and I’m helping the superset team.

This bug is confirmed in the code. The root cause is in the _get_tabs_urls() method in superset/commands/report/execute.py [1], which explicitly constructs new state objects with dataMask, activeTabs, and urlParams all set to None for each tab:

def _get_tabs_urls(
    self, tab_anchors: list[str], user_friendly: bool = False
) -> list[str]:
    return [
        self._get_tab_url(
            {
                "anchor": tab_anchor,
                "dataMask": None,       # ❌ drops stored state
                "activeTabs": None,     # ❌ drops stored state
                "urlParams": None,      # ❌ drops stored state
            },
            user_friendly=user_friendly,
        )
        for tab_anchor in tab_anchors
    ]

The problem originates in get_dashboard_urls(), which retrieves the full dashboard_state from ReportSchedule.extra.get("dashboard") but then only extracts the anchor field and passes a bare list of anchor strings to _get_tabs_urls() [2]. The method signature _get_tabs_urls(tab_anchors: list[str]) makes it impossible to access the original state.

Notably, single-tab reports work correctly because they pass the full dashboard_state directly to _get_tab_url() [3]. The underlying permalink storage mechanism is sound [4] — the issue is purely that multi-tab mode never provides the state.

A fix would involve passing the full dashboard_state to _get_tabs_urls() and spreading it into each per-tab state object, overriding only anchor:

def _get_tabs_urls(
    self, 
    tab_anchors: list[str], 
    dashboard_state: DashboardPermalinkState,
    user_friendly: bool = False
) -> list[str]:
    return [
        self._get_tab_url(
            {
                **dashboard_state,
                "anchor": tab_anchor,
            },
            user_friendly=user_friendly,
        )
        for tab_anchor in tab_anchors
    ]

The existing tests also mirror this gap — test_get_dashboard_urls_with_multiple_tabs explicitly mocks "dataMask": None [5], so the bug was never caught. Adding test cases that verify dataMask preservation in multi-tab scenarios would be important alongside the fix.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.