From 2008ae4f9f6777c4bf5399dbfe0509d1c217bee3 Mon Sep 17 00:00:00 2001 From: Pavel Tiunov Date: Thu, 26 Mar 2026 19:06:12 -0700 Subject: [PATCH] docs: Elaborate on member level cube-view caveat --- docs/content/product/auth/data-access-policies.mdx | 11 +++++++++-- docs/content/product/auth/member-level-security.mdx | 10 ++++++++++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/docs/content/product/auth/data-access-policies.mdx b/docs/content/product/auth/data-access-policies.mdx index 6b405c46d11d1..076b2173efc76 100644 --- a/docs/content/product/auth/data-access-policies.mdx +++ b/docs/content/product/auth/data-access-policies.mdx @@ -240,8 +240,15 @@ dimension in your query. -_When querying a view,_ data masking follows the same pattern as row-level -security: masking rules from both the view and relevant cubes are applied. + + +Unlike [member-level access policies][ref-dap-mls], which are **not** inherited +from cubes when querying through views, data masking rules **are** applied from +both the view and the relevant cubes. If you define masking on both a cube and a +view that uses that cube, the masking will be applied twice. To avoid unexpected +results, define masking rules on either the cube or the view, but not both. + + For more details on available parameters, check out the [`member_masking` reference][ref-ref-dap-masking]. diff --git a/docs/content/product/auth/member-level-security.mdx b/docs/content/product/auth/member-level-security.mdx index 9741647ea7243..69b090bbb10db 100644 --- a/docs/content/product/auth/member-level-security.mdx +++ b/docs/content/product/auth/member-level-security.mdx @@ -10,6 +10,16 @@ Defining whether users have access to [cubes][ref-cubes] and [views][ref-views] similar to defining access to database tables; defining whether they have access to dimensions and measures — to columns. + + +Just like in many SQL databases where table-level column policies are not +inherited by views, member-level access policies defined on cubes are **not** +applied when querying through views. Only the member-level policies defined on +the view itself will take effect. Make sure to define access policies on your +views directly. + + + __By default, all cubes, views, and their members are *public*,__ meaning that they can be accessed by any users and they are also visible during data model introspection.