sadpandajoe commented on code in PR #44128:
URL: https://github.com/apache/superset/pull/44128#discussion_r4019809809
##########
docs/admin_docs/configuration/mcp-server.mdx:
##########
@@ -926,6 +926,23 @@ while True:
page += 1
```
+## Trash Listing (Soft-Deleted Objects)
+
+When the `SOFT_DELETE` feature flag is enabled, deleting a chart or dashboard
moves it to trash rather than removing it outright. The `list_charts` and
`list_dashboards` tools accept a `deleted_state` parameter to surface those
trashed objects:
+
+- `deleted_state="only"` — return only trashed objects
+- `deleted_state="include"` — return live and trashed objects together
+- Omitted (default) — live objects only; trashed objects are excluded
+
+```python
+# List only trashed charts
+result = mcp.list_charts(request={"deleted_state": "only"})
+```
+
+Trashed rows carry a non-null `deleted_at` timestamp in the response
(populated only when `deleted_state` is used). Visibility follows the same
restore-audience scoping as the equivalent REST API filters
(`chart_deleted_state` / `dashboard_deleted_state`): a non-admin caller sees
only the trashed objects they can edit (the same audience that can restore
them), not merely the ones they own; admins see all trashed objects.
Review Comment:
This now conflicts with the tool metadata MCP clients discover: both
`ListChartsRequest` and `ListDashboardsRequest` still say trashed rows are
limited to objects the caller owns, while the filter actually scopes them to
editors. Could those generated schema descriptions be updated with this page so
agents don't enforce the wrong ownership rule?
##########
docs/admin_docs/configuration/mcp-server.mdx:
##########
@@ -926,6 +926,23 @@ while True:
page += 1
```
+## Trash Listing (Soft-Deleted Objects)
+
+When the `SOFT_DELETE` feature flag is enabled, deleting a chart or dashboard
moves it to trash rather than removing it outright. The `list_charts` and
`list_dashboards` tools accept a `deleted_state` parameter to surface those
trashed objects:
+
+- `deleted_state="only"` — return only trashed objects
+- `deleted_state="include"` — return live and trashed objects together
+- Omitted (default) — live objects only; trashed objects are excluded
+
+```python
+# List only trashed charts
+result = mcp.list_charts(request={"deleted_state": "only"})
+```
+
+Trashed rows carry a non-null `deleted_at` timestamp in the response
(populated only when `deleted_state` is used). Visibility follows the same
restore-audience scoping as the equivalent REST API filters
(`chart_deleted_state` / `dashboard_deleted_state`): a non-admin caller sees
only the trashed objects they can edit (the same audience that can restore
them), not merely the ones they own; admins see all trashed objects.
+
+Tools whose resource doesn't support trash listing reject the `deleted_state`
parameter with an error.
Review Comment:
Unsupported list tools currently ignore this field rather than rejecting it,
so `list_datasets(request={"deleted_state": "only"})` succeeds with an ordinary
live listing that a client can mistake for an empty trash result. Should their
request schemas reject the field, or should this sentence describe the actual
behavior?
--
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]
