sadpandajoe commented on code in PR #43499:
URL: https://github.com/apache/superset/pull/43499#discussion_r4076759382
##########
superset/models/sql_lab.py:
##########
@@ -551,6 +551,66 @@ 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 f"{self.database.database_name}.{self.schema}"
Review Comment:
A persisted saved query can have a null `db_id`, but these new datasource
properties immediately dereference `self.database`. Creating or updating a
chart against that row still fails with `AttributeError` during
access/persistence instead of returning a controlled validation or
authorization error. Could this path reject database-less saved queries or
handle the absent database safely?
--
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]
