2 Sets of RLS

[kxie]

If I have tables A, B, and C and want to use them for 2 different dashboards with different rules for row-level security, what would be the best way to do this? 

An example of this would be:

Dashboard X only contains aggregate level information such as total national sales and I want everyone to be able to see this regardless of their role

Dashboard Y contains more granular details on sales where a user should only see rows based on their role.

Since aliases inherit RLS from the physical table, runtime business views don't support RLS, Incorta Analyzer business views don't have joins, the only solution I can think of is to make a physical copy of the relevant tables. Are there any alternative implementations other than making copies of the tables?

[dylanwan]

I will use prebuilt aggregate and use it as the source for Dashboard X in this case.  Make the aggregated data and the granular details as two separate physical objects and define different runtime security filter. 

We don't define the runtime security against the business views but the data returned from querying business views are secured by the runtime security filters applied to the base table of the query.

Runtime security filter is applied to the Analyzer users since they are defined at the physical schema level and applied to those queries.

If the requirement is to secure the data shown on the dashboards and the dashboard users have no access to Incorta Analyzer, we can also use different Dashboard Applied filters to filter out (secure) data.

The difference between a security filter and a regular filter in that a security filter is based on the user context so different users can view different data without creating different dashboards for different users.

[kxie]

Is it possible to prevent certain dashboards from being copied? The issue with prebuilt aggregate tables is that it loses the dynamic filtering.