How to use and troubleshoot access grants / field permissions

[molly_lippsett]

Knowledge Drop

Last Tested: Mar 12, 2020

Documentation for full reference about access_grant

Access grants allow developers to restrict access at the explore, join, view and field level. Access is tied to user attributes. Access grants DON'T restrict dev access in LookML - they DO restrict access in Explore field pickers and queries.
 

SYNTAX

Access grants are built in the model file.
You can define the permission like this:

access_grant: privileged_departments {

user_attribute: department

allowed_values: ["hr", "finance"]

}

Allowed_values use OR logic - any of the values allow access.
 

Access grants are applied at the explore, join, view or field level. You can call the access grant with the required_access_grants parameter. Ex:

view: view_name {

required_access_grants: [privileged_departments]

Required_access_grants use AND logic - you must have allowed values for all grants to have access.
 

GOTCHAS

• This means that combinations of required_access_grants are an intersection of grants, not a union. If you have required_access_grants at all levels (explore, join, view and field) you must have allowed values for all grants to have access. Therefore, a required_access_grants on an object means you must have AT LEAST the allowed value for that grant to have access.
• Required_access_grants are NOT inherited in NDTs
• They are also NOT inherited in field references - if measure A references dimension B and dimension B has a required_access_grant, measure A will NOT have the required_access_grant for dimension B
• They ARE inherited in extended entities and can be overwritten.
• If you are embedding and passing user_attribute values (as would you would, for use with access_grants), keep in mind these show up in the url - and the embed url breaks at 2000 characters. For this reason, if an embed customer is using many of these, we might recommend short user_attribute names and values.

TROUBLESHOOTING

1. Look for the lowest point of access to the highest for all required_access_grants (ie. field, then view, then join, then explore)
2. Make sure the user has ANY of the allowed values for each of the user attributes in ALL applicable access grants
3. Here’s a break down of the front-end behavior when you haven’t been granted access.

Type of Object	If you don’t have permission...
Explore	Cannot see entire look/tile, nor menu nav item. Behaves the same as if you tried accessing a query in production based on an explore that only existed in dev mode.
Field	The query runs without the field. A warning message appears saying, “‘view.field’ no longer exists on View, or you do not have access to it, and it will be ignored.” The warning is suppressed on dashboards.
View or Join	Views and joins are treated as groups of fields, and behave the same as not having access to the whole group of fields within that view or join.