docs: Elaborate on member level cube-view caveat

Author: paveltiunov

docs/content/product/auth/data-access-policies.mdx

@@ -240,8 +240,15 @@ dimension in your query.
 
 </WarningBox>
 
-_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.
+<WarningBox>
+
+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.
+
+</WarningBox>
 
 For more details on available parameters, check out the
 [`member_masking` reference][ref-ref-dap-masking].

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.
 
+<WarningBox>
+
+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.
+
+</WarningBox>
+
 __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.