Granular Permission System

Feature Suggestions
#1

Introduction
Currently the Holistics Permission system serves basic use cases, but when you want to use Holistics for more and more use cases, you start to see limitations such as:

  • An Explorer Role can’t see Metric Definitions
  • Only an Analyst Role and higher can use the SQL Editor (which would also serve other people for ad hoc analysis)
  • When you give someone an Analyst Role, that person will see Dashboards that he/she doesn’t have permissions for. When clicking on a Dashboard, they get the message that they need additional permissions.
  • And many more that I don’t know from the top of my head for now.

Feature suggestion
It would be great if Holistics would have more granularity in roles, and allow for custom roles.
This way:

  • An Explorer who wants to write ad hoc SQL, gets only additional permission for the SQL editor
  • An Explorer who needs access to Metric definitions, gets only additional permissions to see the Metric definitions.
  • Also what can be very useful, is to hide measures/dimensions from some users, and show only Metrics (for user convenience)
  • And a lot of other use cases that I can’t mention now, but I am sure other people have the same.
Make Metric definitions visible to explorers
#2

Thank you @Abdel for sharing your case.
Previously, we designed our Permission System on the working role basis because we believed that most of the companies will follow it:

  • Admin: The most powerful role who controls the whole analytics stack and account
  • Analyst (or data builders): Those who supports Admins in building the data stack; therefore, they are able to access to most of the things except for the admin management/settings
  • Explorer: A hybrid of data builders and data consumers - We introduce this role to serve a group of semi-tech users who can understand and explore data themselves, which can help release the data bottleneck. Therefore, they can explore the underlying data and save results with minimum help from data team.
  • Viewer (or data consumers): Those who is just able to view reports

However, recently we realized that there are more and more complex permission cases that our customers have to deal with, and we totally agree that our team should enhance our permission system to better solve these cases.

And yah you’re right, we believe that custom role would better solve your case: You can add or remove permission rules to a specific default role, and/or create new roles for your team.
However, since Permission System is a complicated beast, we are still waiting for more permission use cases (from other customers) before making decisions on the final approach. So we really appreciate your patience and understanding this time.

Feel free to share with us more about your new use cases on this topic, it will be really helpful for us! Thank you!

Make Metric definitions visible to explorers
#3

Hi @di.hoang , you’re right that different organisations will need different level of permissions structures.

A couple of scenarios not currently catered for…

  1. I should be able to grant selected users permission to add additional data sources, without making them full admin roles

  2. An Explorer can’t create or change dashboards, only ‘private’ ones - they should be able to create ‘organisation’ ones, without exposing the user to the modelling layer

#4

Hi @di.hoang,

Well, I think we need to be able to explore “The single source of truth” to who-ever we need.
So, an important use case is to show definitions of metrics to explorers.
Give SQL Editor access to Explorer type of users etc.