GitHub user mohamedsigservice added a comment to the discussion: RLS condition inconsistently applied inside dataset metric subqueries
@dosu Thanks for the detailed explanation. To summarize my specific situation and close the loop: I have a virtual dataset built on tableau_brand (a materialized view) with complex Jinja2 filters. My metrics require correlated denominators — specifically COUNT(DISTINCT ...) and SUM(...) calculated over a filtered subset of rows that doesn't match the main query's GROUP BY dimension. This forced me to use either: - Subqueries inside metrics → RLS is injected inside the subquery via ALLOW_ADHOC_SUBQUERY, but inconsistently (sometimes the RLS clause references columns not present on the subquery's table, causing errors or wrong results) - CTEs inside the dataset SQL → RLS is NOT injected inside CTE bodies referencing the base table directly, making CTEs an effective bypass of RLS — which is the opposite of what I want Based on your explanation, the root cause is clear: CTE references are explicitly excluded from exp.Table detection, so tables inside CTE definitions that are named after the base table don't get RLS injected. The only viable workaround I see given the current architecture is to move the aggregation logic to PostgreSQL-level views or functions, and apply PostgreSQL native Row Level Security directly on the base tables, so RLS is enforced at the DB level regardless of how Superset constructs the query. Is this the recommended long-term approach? Is there any planned support for CTE-aware RLS injection, or a way to explicitly declare that a CTE body should inherit the RLS policy of its base table? GitHub link: https://github.com/apache/superset/discussions/40400#discussioncomment-17060537 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
