Hello Looker Team
I am confused between user roles vs content access. Why they both are different? For example:
part 1: - If I have created a role:-
marketing role = marketing models + developer permissions
This role means that a user can only create looks, dashboards, see data from marketing models and play with it, (eg: access data, create, see lookml dashboards etc). I assigned that role to ‘marketing’ user group
Part 2: There is content folder called ‘marketing’ which stores all the marketing content (eg: looks, dashboard), and on that folder I only give ‘view’ access to marketing user group.
Part 1 and part 2 contradicts each other. On one side I am telling users to access marketing models and create content and on the other side I am telling the same users just to ‘view’ content in ‘marketing’ folder
Can someone please clarify this confusion
Thanks a lot!
Raman
Solved! Go to Solution.
Hi rsingh,
Ok, let’s stick to your example of the Marketing team.
There are a lot of cases where you would want to customise content access independent of data access, for example:
(1) In a lot of companies, the creators of dashboards are not also the consumers of these dashboards. Therefore they would want to only allow the Marketing team to only view the content in the Marketing folder and not accidentally delete a dashboard, move a tile etc; or save new content in this folder which is not relevant to all users.
(2) There are dashboards which are currently being developed by the analysts in the Marketing team which are still work in progress and not yet ready to be shared with the wider Marketing team, therefore they would keep them in a (hidden-to-the-world) Marketing Dev folder before moving them to the Marketing Prod folder.
(3) Sometimes content of a dashboard can come from multiple models, for example senior management reporting where data access restrictions are not required. In this case you would want them to only see one folder rather than every shared folder in the company.
It does make sense for access to be managed at these levels, especially because a lot of the times there is no requirement for data access to be segregated based on teams.
Hope this helps!
Best,
Hi rsingh,
Content access control is a good way to keep your folders (particularly shared folders) tidy.
It is possible to give your Marketing user group edit access to the Marketing folder if you wish to:
Do you not see the option to give them Edit access to the Marketing folder for the Marketing group?
Best,
Hello @Maddie
I apologize if I didn't explain it clearly. I am actually confused to understand the difference between Content Access and Data Access features of Looker
If we give ‘Model A’ data access to marketing users (Looker role), then ideally they should automatically have access to all the content (looks/dashboard) which are related to that model in shared folders
So why we need to create additional ‘content access’ on top of ‘data access’ ? Why there is an extra layer?
Thank you
Raman
Hi rsingh,
No problem, I get where you are coming from now!
The content management is in place to control who can add or delete content in a folder.
It could be that you have a shared folder called Finance which contains information coming from the finance model and are accessed by the whole company including the groups Finance, C-Suite, Marketing team etc, but only a small group group of people (i.e. the Analytics team + the Finance team) who can modify the dashboards.
Admins find this article really useful in getting their heads around the security levels available in Looker.
Best,
Hello @Maddie
Thank you for your response
In your example, if the marketing team doesn't have permissions to view ‘Finance’ model sets (roles) then why would they even have access to the ‘Finance’ folder in the first place?
so technically, If I (admin), only want marketing users to see data of marketing models, then why do I have to again define their content access for ‘Finance’ folder
Best
Raman
We generally have a 1:1 role to group setup and then assign people into groups which therefore inherit the role, then the groups are used for content management as well. More accurately we nest groups and grant parent groups a role and Use children to handle folder access - we have a fairly open permission structure.
If the permissions were not as granular like how you are getting at then it would make some setups impossible.
Hi rsingh,
Ok, let’s stick to your example of the Marketing team.
There are a lot of cases where you would want to customise content access independent of data access, for example:
(1) In a lot of companies, the creators of dashboards are not also the consumers of these dashboards. Therefore they would want to only allow the Marketing team to only view the content in the Marketing folder and not accidentally delete a dashboard, move a tile etc; or save new content in this folder which is not relevant to all users.
(2) There are dashboards which are currently being developed by the analysts in the Marketing team which are still work in progress and not yet ready to be shared with the wider Marketing team, therefore they would keep them in a (hidden-to-the-world) Marketing Dev folder before moving them to the Marketing Prod folder.
(3) Sometimes content of a dashboard can come from multiple models, for example senior management reporting where data access restrictions are not required. In this case you would want them to only see one folder rather than every shared folder in the company.
It does make sense for access to be managed at these levels, especially because a lot of the times there is no requirement for data access to be segregated based on teams.
Hope this helps!
Best,
We generally have a 1:1 role to group setup and then assign people into groups which therefore inherit the role, then the groups are used for content management as well. More accurately we nest groups and grant parent groups a role and Use children to handle folder access - we have a fairly open permission structure.
If the permissions were not as granular like how you are getting at then it would make some setups impossible.
Hello @IanT
Thank you for your response
I am trying to understand a use case here below:
If ‘finance group’ only have finance model access (‘Data Access’) , and we also gave them 'Manage access/edit’ access to marketing content folder, can they:
Open the looks and see the marketing content (looks/dashboard0?
Can they edit the looks (even if they don’t see the data, part 1)?
Can they delete/copy/rename the looks?
Thank you
Raman
Hi rsingh,
Ok, let’s stick to your example of the Marketing team.
There are a lot of cases where you would want to customise content access independent of data access, for example:
(1) In a lot of companies, the creators of dashboards are not also the consumers of these dashboards. Therefore they would want to only allow the Marketing team to only view the content in the Marketing folder and not accidentally delete a dashboard, move a tile etc; or save new content in this folder which is not relevant to all users.
(2) There are dashboards which are currently being developed by the analysts in the Marketing team which are still work in progress and not yet ready to be shared with the wider Marketing team, therefore they would keep them in a (hidden-to-the-world) Marketing Dev folder before moving them to the Marketing Prod folder.
(3) Sometimes content of a dashboard can come from multiple models, for example senior management reporting where data access restrictions are not required. In this case you would want them to only see one folder rather than every shared folder in the company.
It does make sense for access to be managed at these levels, especially because a lot of the times there is no requirement for data access to be segregated based on teams.
Hope this helps!
Best,
Thats a great example @Maddie . 🙂 Thank you very much for that. Its helps me understand this concept better
I just love Looker and its amazing community. 😄
Hi rsingh,
No problem at all, I am happy to have helped
Have fun learning Looker!!!
Best,
Why don’t you suck it and see (try it for yourself) - setup some users and the permissions structure and sudo as different users.