[ https://issues.jboss.org/browse/TEIID-5802?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5802: --------------------------------------- Now that I'm remembering this problem more there is a reason why we simply warn of this scenario. When you create a materialized target table the only way to preserve the masking / row security is to transitively determine all possible applications from the constituent tables/views and attempt to re-apply them to the materialization target table created without any security applied transitively as well. In general this is very difficult - for example many of the columns that have row based security may not even be exposed by the materialized view (which at a minimum requires creating an intermediate view), or are involved in aggregation, etc. What you have here is a simple enough of a case, such that you could envision Teiid creating a materialization target table as a superset, then apply the row/column security on top of that. However with additional complexity that will quickly not work. I agree though that things are in a weird middle ground. Materialization target tables are being created with potentially mixed application of row/column security based upon whoever the calling user that triggers the load. The simplest way to make this consistent is to create the materialization target tables without any security applied transitively, but without some automated process of applying security on top it would be up to the user to redefine the security on the materialization target. There was a legacy feature of scoping materialized views to a user, but was removed by TEIID-5427 as it did not align with any materialization management strategy. -- This message was sent by Atlassian Jira (v7.12.1#712002)