[GitHub] [incubator-superset] villebro commented on issue #8699: [SIP-29] Add support for row-level security

[GitBox <gi...@apache.org>]

villebro commented on issue #8699: [SIP-29] Add support for row-level security
URL: https://github.com/apache/incubator-superset/pull/8699#issuecomment-559954723
 
 
   Great initiative! I looked at the PR for this SIP and a few things came to mind:
   
   To address the issue you raise in the docs where belonging to two departments results in zero rows (`WHERE dept = 1 AND dept = 2`), I propose changing the `Clause` field to JSON, putting each clause behind a key, which are later ORed together. Example: There are four RLS filters specified for a table: two for departments ("Finance", "Risk") and two for time history ("30 days", "90 days").
   "Finance" role:
   ```json
   {
       "dept": "dept_id = 'Finance'"
   }
   ```
   "Risk" role:
   ```json
   {
       "dept": "dept_id = 'Risk'"
   }
   ```
   
   "30 days" role:
   ```json
   {
       "history": "report_date >= current_timestamp() - 30"
   }
   ```
   
   "90 days" role:
   ```json
   {
       "history": "report_date >= current_timestamp() - 90"
   }
   ```
   
   Now, if a user belonged to all four groups, this would result in the following WHERE clause:
   ```sql
   ((dept_id = 'Finance') OR (dept_id = 'Risk')) AND 
   ((report_date >= current_timestamp() - 30) OR (report_date >= current_timestamp() - 90))
   ```
   
   In this case the user would see 90 days of history, and also all rows for Finance AND Risk.
   
   Also, I think it would be good to be able to define a default WHERE clause if a user doesn't belong to any of the specified groups.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org