sadpandajoe commented on code in PR #43499:
URL: https://github.com/apache/superset/pull/43499#discussion_r4289671006
##########
superset/models/sql_lab.py:
##########
@@ -602,6 +602,68 @@ def to_dict(self) -> dict[str, Any]:
"id": self.id,
}
+ @property
+ def name(self) -> str:
+ """
+ Expose ``label`` as ``name`` so callers that treat a ``SavedQuery`` as
+ a generic datasource (e.g. chart create/update commands) can rely on
+ a uniform ``name`` attribute across all datasource types.
+
+ ``label`` is a nullable column, so fall back to an id-based name
+ rather than returning ``None`` from a property typed as ``str``.
+ """
+ return self.label or f"Saved query {self.id}"
+
+ @property
+ def schema_perm(self) -> Optional[str]:
+ """
+ Schema-level permission string, mirroring ``Query.schema_perm``.
+
+ Required so that ``SecurityManager.raise_for_access(datasource=...)``
+ and the ``Slice`` ``before_insert``/``before_update`` listener (which
+ copies ``perm``/``catalog_perm``/``schema_perm`` onto the chart) can
+ treat a ``SavedQuery`` like any other datasource instead of raising
+ ``AttributeError``.
+ """
+ return security_manager.get_schema_perm(
+ self.database.database_name, self.catalog, self.schema
+ )
+
+ @property
+ def catalog_perm(self) -> Optional[str]:
+ """Catalog-level permission string; see ``schema_perm`` above."""
+ return security_manager.get_catalog_perm(
+ self.database.database_name, self.catalog
+ )
+
+ @property
+ def perm(self) -> str:
+ """Object-level permission string; see ``schema_perm`` above."""
+ return f"[{self.database.database_name}].[{self.name}](id:{self.id})"
Review Comment:
Query and SemanticView sharing the shape is not the same exposure: this PR
is what makes a saved-query row resolvable through `Slice.resolved_datasource`
and the no-viewer chart fallback, so a user holding only a same-name, same-id
dataset grant can read an unrelated saved-query chart. Could the saved-query
perm be namespaced, or the fallback skip saved_query, here, with the
shared-namespace cleanup tracked separately?
##########
superset/commands/chart/utils.py:
##########
@@ -29,10 +29,17 @@
def validate_chart_datasource_type(datasource_type: str) -> None:
"""Accept persistent chart sources with names and type-aware access
policies.
- SQL Lab queries are registered datasource types but are not persistent
- chart sources; accepting all DatasourceDAO registrations would include
them.
+ A raw SQL Lab ``query`` is a registered datasource type but not a
+ persistent chart source, so it's excluded here; accepting all
+ DatasourceDAO registrations would include it. A ``saved_query`` is
+ explicitly persisted and named by the user, so it's accepted alongside
+ ``table``/``semantic_view``.
"""
- if datasource_type not in (DatasourceType.TABLE,
DatasourceType.SEMANTIC_VIEW):
+ if datasource_type not in (
+ DatasourceType.TABLE,
+ DatasourceType.SEMANTIC_VIEW,
+ DatasourceType.SAVEDQUERY,
Review Comment:
Charts of this type become creatable as soon as this merges, and each one
exports without `dataset_uuid`, so the bundle fails `ImportV1ChartSchema` on
reimport. Is there a tracked issue for the importer path, and could export at
least skip or flag these charts so users are not handed a bundle that cannot be
imported?
##########
superset/commands/chart/utils.py:
##########
@@ -33,15 +33,22 @@
def validate_chart_datasource_type(datasource_type: str) -> None:
"""Accept persistent chart sources with names and type-aware access
policies.
- SQL Lab queries are registered datasource types but are not persistent
- chart sources; accepting all DatasourceDAO registrations would include
them.
+ A raw SQL Lab ``query`` is a registered datasource type but not a
+ persistent chart source, so it's excluded here; accepting all
+ DatasourceDAO registrations would include it. A ``saved_query`` is
+ explicitly persisted and named by the user, so it's accepted alongside
+ ``table``/``semantic_view``.
"""
if (
datasource_type == DatasourceType.SEMANTIC_VIEW
and not is_semantic_layers_enabled()
):
raise ValidationError(SemanticLayersDisabledError.message)
- if datasource_type not in (DatasourceType.TABLE,
DatasourceType.SEMANTIC_VIEW):
+ if datasource_type not in (
+ DatasourceType.TABLE,
+ DatasourceType.SEMANTIC_VIEW,
+ DatasourceType.SAVEDQUERY,
Review Comment:
Agreed it is a visibility gap rather than an escalation, but the same user
would see create succeed and then get a 404 on the chart they just made, which
this PR introduces. Could the follow-up issue be linked here, or `ChartFilter`
and `DashboardAccessFilter` get the `SavedQuery` join now?
--
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]
