Scheduled reports with filters

[billbelanger]

Is it possible to create scheduled reports and specify filters for existing charts? We are looking to generate the same report for multiple clients, applying filters to restrict the data in the report, customizing for each client. Since the reporting UI doesn't allow for customized filters for each report, so far, the only way we've been able to figure out how to do this would be to generate a unique chart for each client. This might work when we have a small handful of clients, but will certainly not scale. Or possibly, we could create Alerts for each client, which do allow for customized filters, and the alert 'triggers' when 1 > 0 (meaning all the time).

We came across an earlier discussion in which dosubot recommends using the API to define a filters field when creating the report. However, reviewing the swagger docs & the code directly, it doesn't look like filters is a field (maybe it was when dosubot responded, since that post is almost 2 years old).

We've looked into doing something custom within the celery config, but we were a little out of our depth and figured we should check here before we go down a rabbit hole.

So, is there something we've overlooked or is this simply something Superset can't do natively at the moment? Thanks for your time.

[billbelanger]

Actually, I'm going to correct myself. The Alerts approach doesn't work either. We could put custom filters in the 'condition', but not in the results that get exported.

[dosubot[bot]]

That's correct — alerts evaluate a condition query separately from the report content, so custom filters in the condition won't affect the exported chart/dashboard data.

As I mentioned in my earlier reply, the approach that should work for your use case is dashboard-type report schedules with the extra JSON field. Each report schedule can carry its own native filter state via extra.dashboard.dataMask, so the same dashboard renders with different client-specific filters per schedule. This requires:

1. The ALERT_REPORT_TABS feature flag enabled [1]
2. Native filters set up on the dashboard
3. One report schedule per client created via the API, each with a different dataMask in extra [2] [3]

This is API-only — the UI doesn't expose the extra field for editing filter state per report. But it avoids duplicating charts and should scale to many clients. Let me know if you'd like help putting together the API call.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[billbelanger]

Thanks @dosu that lead us in the right direction. To follow up and provide a fuller answer, for anyone else coming across this issue, we were able to generate a filter'd report using the API for the create (POST /api/v1/report). In order to do so, we had to do the following:

First, we had to get the list of native filters for the dashboard: GET /api/v1/dashboard/:id, which provided us with this in the response:

{
  "result": {
    ...
    "json_metadata": "<stringified json>"
  }
}

If we unpack the json_metadata, we find (apologize for the verbosity here, but I've stripped away most of what wasn't important):

{
  "native_filter_configuration": [
    {
      "id": "NATIVE_FILTER-abcdefg",
      "name": "<Human readable filter name>",
      "filterType": "filter_select",
      "targets": [
        { "column": { "name": "<column name>" }, "datasetId": 01234 }
      ],
      "defaultDataMask": {
        "extraFormData": {
          "filters": [
            { "col": "<column name>", "op": "IN", "val": ["<default filter value>"] }
          ],
        "filterState": {
          "validateMessage": false,
          "validateStatus": false,
          "label": "<default filter value>",
          "value": ["<default filter value>"]
        }
      },
      "type": "NATIVE_FILTER"
    }
  ]
}

Taking those values, we can now construct our API call (POST /api/v1/report) to create the filter'd report. The important part here is the extra field:

{
  "active": true,
  "creation_method": "alerts_reports",
  "extra": {
    "dashboard": {
      "nativeFilters": [
        {
          "nativeFilterId": "NATIVE_FILTER-abcdefg",
          "columnName": "<column name>",
          "filterType": "filter_select",
          "filterValues": ["<filter value I want>"]
        }
      ]
    }
  },
  ...
}

I tested this a couple of times and it worked in our DEV environment with one or multiple filters. No need for the dataMask mentioned by Dosu so far as I could tell. Maybe it does something I'm unaware of.

This really felt like it maybe could be documented somewhere as I didn't think this was too outlandish a request. I'm happy to write up the doc / help file if someone would like to point me to where it belongs, or if they could tell me why the dataMask is important, I could include that too.

[dosubot[bot]]

Glad that helped, and thanks for the detailed write-up — that's really useful for anyone finding this thread.

To answer your question about dataMask vs nativeFilters: they actually serve different roles in the codebase. The DashboardPermalinkState type that the report execution code uses defines dataMask as the field for filter state [1], and that's what gets passed to CreateDashboardPermalinkCommand when generating the permalink for rendering [2]. Meanwhile, nativeFilters was introduced by PR #38715 as a validation mechanism — it checks that the native filter IDs you reference actually exist on the dashboard and can deactivate reports when filters are deleted.

So it seems like the nativeFilters structure you used works for specifying which filters to apply and their values, while dataMask is the permalink-level state that the rendering engine actually reads. It's possible that both paths end up producing the correct output during execution, but nativeFilters may provide the added benefit of validation against stale filter references.

As for documentation — I'd be happy to save this as a knowledge article on my end so I can surface it for others with the same question. Would you like me to do that?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[billbelanger]

@dosu Sure, go ahead and save it. I will point out that I tried the API calls with JUST the dataMask and it did not work. The reports didn't filter at all. Then I tried it with both the dataMask and the nativeFilters, and it worked. Then I tried it with just the nativeFilters by itself and that also worked, so that's when I determined the dataMask was unnecessary.

[dosubot[bot]]

That's really helpful clarification — thanks for testing all three combinations. So to summarize: nativeFilters is the field that actually drives the filtering behavior, and dataMask alone doesn't work. Good to know, and I stand corrected on my earlier suggestion.

Unfortunately I don't have write permissions to save this to the knowledge base — that requires a library admin or owner. If a project maintainer or admin wants to save this, they can ask me to do so, or they can add it directly at app.dosu.dev.

Either way, your write-up in this thread is thorough and should be very findable for anyone searching for this topic. Appreciate you documenting the full solution!

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[billbelanger]

I suppose it's possible I was just using the wrong values in dataMask. Here's what I had tried. I'm not sure I recall where I pulled this structure from, but I think it was something I found in the 'advanced json edit' section of the dashboard in the UI.

{
  ...
  "extra": {
    "dashboard": {
      "dataMask": {
        "NATIVE_FILTER-abcd": {
          "id": "NATIVE_FILTER-abcd",
          "extraFormData": { "filters": [ { "col": "<column name>", "op": "IN", "val": ["<desired value>"] } ] }
          "filterState": {
            "validateMessage": false,
            "validateFilterValues": false,
            "label": "<desired value>",
            "value": ["<desired value>"]
          },
          "ownState": {}
       }
      }
    }
  }
}