[ https://issues.jboss.org/browse/TEIID-2311?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2311: --------------------------------------- Added the initial check-in of row-based security. The approach is basically as outlined above. A permission element can now have a condition child: <permission> <resource-name>SCHEMA.TABLE</resource-name> <condition>COLUMNA=user()</condition> <allow-read>true</allow-read> ... </permission> The affected resource can be a table/view or procedure. Multiple conditions against the same resource are accumulated disjuctively. Unlike data roles, the conditions are always applied (not just at the user query). So it may be typical that the permissions are written for an any authenticated role and generalized, such as shown above with the use of the user function. The condition can be any valid sql referencing the projected columns, but the current implementation will not correctly handle subqueries for bulk inserts (that could be addressed later if needed). The condition is applied conjunctively to update/delete/select where clauses. That means that those queries will only ever be effective against the subset of rows that pass the condition, i.e. SELECT * FROM TBL WHERE blah AND condition inserts and updates against tables are further validated so that the insert/change values must pass the condition (evaluate to true) for the insert/update to succeed - this is effectively the same a sql constraint. This will happen for all styles of insert/update - insert with query expression, bulk insert/update, etc. However this can inhibit pushdown in some circumstances as we have to check the values for each row. inserts/updates against views are not checked with regards to the constraint. Further changes may be necessary to ensure that performance is not unduly harmed when the condition cannot be pushed down - most optimizations are already flexible about this case, but we could more aggressively look at raising the criteria to produce a better plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira