Hi Ville, Thanks for the resopnse. We have an account_id column in each table we access with superset. Each user is allowed to see only rows of data for matching account IDs (a user can be assigned to one or more account_ids). No matter which datasource he’s using. Iin worst case it could be added to all as it’s not that many, but security wise a one first all approach would be favourable.
Do I understand correctly the Ninja templates will also be applied to all Dashboards & Slice queries (not only SqlLab)? The docs wasn’t that pecise here and the infos I found sounded like it’s a SQLLab feature only. Thanks, Dennis > On 17. Jul 2019, at 20:22, Ville Brofeldt <[email protected]> wrote: > > Hi Dennis, > > depending on your data structure, you might be able to leverage the > built-in support for Jinja templates, which can be embedded in SQL queries, > where or having clauses. So you could, for example, add a filter "username > = '{{ current_username() }}'" to filter only rows that apply to the logged > in user (btw, I also recently put through a PR #7816 to address problems > arising from using Jinja templating with caching). If not, it would be > interesting to hear more about your requirements to see if it can be solved > with existing functionality, or how much effort it would require to > implement. I suggest opening an issue on GitHub so this can be explored in > more detail. > > Ville > > On Wed, Jul 17, 2019 at 4:40 PM Dennis Meyer <[email protected]> wrote: > >> Hi, >> I’m, wondering which is the best approach to filter data per tenant. I saw >> there has been some PR, but it seems it’s dropped/never made it into the >> official release. >> >> https://github.com/apache/incubator-superset/issues/5581 < >> https://github.com/apache/incubator-superset/issues/5581> >> >> We have OAuth integration implemented but it’s pretty much useless if you >> cannot filter per client. >> Can someone here elaborate the goto solution out of the box and the >> potential customizations? I’m thankful for any advise or hint. >> >> Thanks in advance, >> Dennis >> >>
