[GitHub] [incubator-superset] durchgedreht opened a new issue #7887: Filtering data per user on DB table level (Customer or Tenant Support)

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

durchgedreht opened a new issue #7887: Filtering data per user on DB table level (Customer or Tenant Support)  
URL: https://github.com/apache/incubator-superset/issues/7887
 
 
   **Is your feature request related to a problem? Please describe.**
   
   Most enterprise data sets are divided by a major ID column that strictly groups data of customer accounts into silos that are . not matched in 99% of the use cases - let's call the column "account_id" for a simple example. User Alice is allowed to see data `"WHERE  account_id = 1"`, Bob is allowed to see data `"WHERE account_id=2"` and Chris can see  `"WHERE account_id  in (2 ,3)" ` 
   
   This filter should be applied BEFORE any data hits dashboard or Slice logic. Ideally speaking one user should see only his data in the table - as if none else would use the system. 
   
   **Describe the solution you'd like**
   
   It would be great to have a general mechanism to define a column filter that always matches a predefined user criteria. In the perfect implementation this would be a selection of the users metadata against a table column:
   First go to" Sources/tables/Edit Table"
   There will be a new tab "FILTERS"
   Here you can select a column and a criteria the value of the column needs to match against. The criteria can be obtained from the user object in the easiest implementation. In the given example it would be:
   
   Table: my_fact_table
   Column: account_id
   Criteria:
   `my_fact_table.account_id = user.account_id (direct single match)`
   OR  
   `my_fact_table.account_id in user.account_ids (1:many match)`
   
   In some use cases even a combination of two of those columns would make sense (think about sellers and buyers and a deal incorporating a buyer_id and seller_id). But this might be the last 20%.
   
   **Describe alternatives you've considered**
   
   There's potentially some not as convenient work around possible with JINJA. The docs are suboptimal here and it is also very SqlLab focussed. It would be great to have some better documentation how to use JINJA in this use case and potentially even point out how to deal with the users metadata better (most users will likely also be using SSO and potentially get the control data from a different app using SSO/OAuth or even a REST call).  
   
   **Additional context**
   
   The functionality does not describe  a full tenant support, but the most basic and most central topic would be covered: Clean separation of data. This looks like be a basic ask of many users in the data world. Implementation effort should be minor considering templating can be used internally.

----------------------------------------------------------------
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