View the original community article here
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
- Look for the lowest point of access to the highest for all required_access_grants (ie. field, then view, then join, then explore)
- Make sure the user has ANY of the allowed values for each of the user attributes in ALL applicable access grants
- 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. |