sadpandajoe opened a new pull request, #46045: URL: https://github.com/apache/superset/pull/46045
### SUMMARY A dataset that is used only as the source of a dashboard native filter (no chart is built on it) was reported as having no dependents. `DatasetDAO.get_related_objects_for_datasets` found dashboards only through their charts, so the dataset delete confirmation (single and bulk) showed no warning and the dataset could be deleted, leaving the dashboard's filter pointing at a dataset that no longer exists. The same lookup backs the `affected_dashboard_count` that the MCP `delete_dataset` tool reports. The lookup now also returns dashboards whose native filters (`native_filter_configuration`) or display controls (`chart_customization_config`) target one of the requested datasets. Each dashboard is still listed once even when it matches through charts and filters, and the response shape is unchanged. Design notes: - Filter targets live in untyped `json_metadata` text, so the query selects only `(id, json_metadata)` for non-deleted dashboards whose metadata contains `"datasetId"`, then verifies the targets exactly in Python. Missing, empty, invalid or non-object metadata and malformed filter configuration never match and never raise. - `dashboard_dataset_ids` (previously private to dashboard export) moves to `superset/dashboards/dataset_references.py`, because importing it from `superset.commands.dashboard.export` into the DAO is a circular import. Export and asset export import it from the new module, and it now tolerates malformed configuration instead of raising. - The database-rename permission sync only needs the charts built on a dataset, so it calls a new `DatasetDAO.get_charts_for_datasets` instead of the full related-objects lookup and does not pay for the metadata scan. Out of scope: the dataset Usage tab lists its rows from the chart list, so a dashboard linked to the dataset only through a native filter still has no row there; that needs a UI design decision and is not changed here. `DatabaseDAO.get_related_objects` has the same chart-only dashboard walk and is also left alone. ### Root Cause `get_related_objects_for_datasets` selected charts with `datasource_id IN (...)` and then dashboards through `JOIN Dashboard.slices`. It never read `Dashboard.json_metadata`, where a native filter references its source dataset in `targets[].datasetId`. The single and bulk related-objects endpoints and the MCP delete tool share that helper, and `DeleteDatasetCommand` itself does not check for dependents, so the confirmation is purely advisory and was the only protection. The chart-only walk predates native filters and was kept when the helper was generalised to a list of datasets for bulk delete, so this was never handled rather than a regression. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF Before: deleting a dataset whose only dependent is a dashboard native filter shows no chart or dashboard warning. After: the delete confirmation lists the dashboard. Screenshots and a recording of both states will be added to this description. ### TESTING INSTRUCTIONS 1. Create a dataset that no chart uses. 2. On a dashboard, add a native filter (for example a Value filter) whose dataset is that dataset, and save the dashboard. 3. In the dataset list, choose delete on that dataset (or select it and use bulk delete). The confirmation now names the dashboard. 4. `GET /api/v1/dataset/<id>/related_objects` and `GET /api/v1/dataset/related_objects/?q=...` include the dashboard under `dashboards`. Automated: `pytest tests/unit_tests/dao/dataset_test.py tests/unit_tests/dashboards/dataset_references_test.py tests/unit_tests/commands/databases/sync_permissions_test.py` and `pytest tests/integration_tests/datasets/api_tests.py -k related_objects`. The regression test `test_related_objects_include_dashboards_filtering_on_the_dataset` fails on `master` (`assert [] == [1]`) and passes with this change. ### ADDITIONAL INFORMATION - [ ] Has associated issue: - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [ ] Introduces new feature or API - [ ] Removes existing feature or API -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
