@di.hoang responding to https://community.holistics.io/t/holistics-product-roadmap/616/21?u=will.b
Because of the very sophisticated user-attribute-based options for doing row and column-based protections the thing I was surprised to find that simpler table-level permissions are missing.
My use case centers around the fact that you can’t do a single report joining across datasets, even if they are backed by the same data source.
I wanted to make separate datasets for marketing, finance, and ops, and give the key users in each department access to just those datasets, which is easily done at the moment.
However, if there are a few individuals who need to do reports across those boundaries, the options aren’t great:
- Make those datasets and also make one super-dataset. This has the problem that you need to know whether you are going to stay within one of the smaller datasets or need the union dataset when you start: if you use the smaller dataset, you have to start your report from scratch when you decide you want to add a column that needs the larger dataset (there’s no way to move reports between equivalent datasets right?); or if you use the union dataset, you aren’t going to be able to hand over that dash to the relevant team later, because they don’t have access to the union dataset.
- Put everything in one super-dataset from the start, but use permissions to control which groups can see the tables outside of their needs. This is a better conceptual fit for our app, where the data genuinely is part of one dataset (it’s all from one app), and it makes it easier to change the access boundaries without people needing to recreate anything.
I wanted to do 2, which is the approach I’ve tried in other products I’m testing. But I can’t see an easy way to do it in Holistics.
So my request for permissions 3.0 is simply that the existing dataset-level user/group permissions system be finer grained, down to table level.