Conditional hiding of groups, dimensions, measures

What feature should I use if I want the following scenario:

Specific group of people (based on either user attribute or preferably access grant) can see dimension but everybody can view looks and dashboards containing it?

I would like to limit the amount of field groups visible to certain userbase because the list is growing and so does the amount of confusion and questions. I would still like them to be able to run looks and dashboards containing such fields…

1 Like

Regarding your last sentence - I think you’re asking about a conditional hide on a field-level. If so, I’d love to know if this is possible too.

@bens indeed… Actually I’m going to split this topic into two parts.

Mod please move these comments here:

Moved!

Basically, you’d like to just hide it from the Field Picker (the list of fields on the left side) for certain users, but allow them to still see it if it’s in queries?

One questionable way to do this would be to extend the views in question and have one view with hidden: yes on the fields in question. You’d also have to set up separate/extended explores I guess, and grant access to each explore (with access grants) based on that user attribute or group membership. The problem is that then you get 2 separate explores being used, which is redundant and confusing.

If you just want to clear things up, I suppose you could also label the fields differently based on a user attribute— So you could just add “DONT USE” or make the label blank depending on a user attribute, but that seems a bit hacky/might even make things more confusing.

Anyone have a better idea? I feel like there must be a more clever way…

Izzy, has your team ever considered conditional hides set on a field-level, to be linked with access grants? I’m almost picturing something like the required_access_grants, but instead it would be hidden_unless_granted (and this is why I’m not in marketing):

dimension: thing_to_restrict {
type: number
  hidden_unless_granted: [can_view_fieldgroup_x]
  }

Edit: Just to explain this a bit better, the difference between this and a required_access_grant as I see it, is that the hidden_unless_granted would only speak to the visibility of the field, and therefore would not restrict the field’s ability to be queried, nor any fields derived from it, but would simply not list it in the Field Picker.

I heard that some people use a conditional statement in the hidden field based on user attribute like hidden: user_attribute.team = <name> but there’s no global scope where you can change it like with grant access.

Basically Looker usage has grown exponentially at our company, so has the amount of data. We want to build comprehensive models and views but don’t want to interrupt the status quo for certain users that don’t need to see it/use it.

I don’t think this is possible, but would be interested to know if you have an example of it! I know that liquid isn’t usable in the hidden: parameter, so I wonder if I’m forgetting something.

Your use case makes total sense!

Yes, I think the liquid there isn’t possible and my source confirmed that perhaps it was in a different place.

But it would still be nice to have a way of controlling the UI without limiting the ability to run queries. Very often I want to build a look for somebody that they just run and that’s it but then they start going through different fields and ask why I used this and that

Setup a general model with some explores which are extension: required and then create a model for each business group which is curated specifically for them and extend these explores. Then permission those model files appropriately.

2 Likes

It is an idea but probably less manageable than some kind of ui permission sets imho

Of course but that’s not real at the moment!
Will give you some other benefits as well probably and the maintenance is minor.

1 Like

I would be interested in such a feature too, so that the explores don’t become monsters only to satisfy the needs of the savvy analysts and you can keep it contained.

1 Like

Dawid, on my environment, I’ve set up two main ways to handle restricting field/field data conditionally based on learnings on here:

  1. For circumstances where you want a group/dimension/measure hidden (meaning its data should still accessible to fields derived from it), you can establish an access grant, build an associated user attribute, and put a required_access_grant parameter within the fields you’d like to restrict

Somewhere in your explore you’ll require an access grant defined (as well as a user attribute configured). I’ve found that I can usually stick with two values for all users for many user attributes like this (yes/no):

access_grant: view_sales {
  user_attribute: can_view_sales
  allowed_values: ["yes"]
}

Then on the field(s) you’d like hidden conditionally:

  measure: total_sales {
    description: "Sales ($)"
    label: "Total Sales ($)"
    type: sum
    sql: ${sales} ;;
    value_format_name: usd_0
    required_access_grant: [view_sales]
  }
  1. When you’d like the data to be scrubbed instead so the field is visible but the data isn’t (which more importantly restricts not just the fields, but any fields built on data from it such as aggregates), you can use Liquid to do so. You can also annotate this to your users through Liquid labels, which I do for some fields with not-yet-validated data, where a select few users have access to the data and need to tell them it’s not ready-for-production data. The rest of the users have the field hidden through the method above. Because a user who shouldn’t have access to this data should also not have access to data derived from it, I’ve opted in some cases to use both this method and the previous one on the same field.

What Method 2 looks like in practice on its own (just add a required_access_grant to also conditionally hide):


dimension: sales_beta {
    type: number
    sql: 
    {% if _user_attributes['can_view_sales'] == 'no' %}   0
    {% else %} ${TABLE}.Sales
    {% endif %} ;;
    label:   
    "{% if _user_attributes['can_view_sales'] == 'no' %}   Total Sales ($) - Beta
    {% else %} Sales values redacted
    {% endif %}"
  }

Hope this helps, Dawid!

1 Like

Wait, so with access_grants people will be able to run queries built with, let’s say, a measure that has the access grant they don’t have?

That’s correct if you use access_grants. That’s why in some cases I’ve both added an access_grant (so the field isn’t visible to some), and also implemented the Liquid logic to redact the data for any downstream fields sourced from it.

hmm interesting, I created this topic because the access grant stopped people from being able to run looks for which you need the grant but I’ll double check, perhaps I missed something

@bens just to confirm access_grant doesn’t allow the user to run anything with that field if they don’t have the access. Of course it makes sense because at the moment it’s a black & white world. Either you have access or not, whereas I would kill for a feature to clean up the field groups but still allow them to see the field used in data table and visualisation

@Dawid_Nawrot Now I understand - this was my mistake!

What I was saying is that a user can actually access data derived from an access_grant restricted dimension/measure. For example, I can use an access_grant to hide my cost measure, but unless I also apply that access_grant restriction to my measure for profit which is derived from it, a user could feasibly deduce what the costs are if they have the rest of the equation.

In looking now, you’re correct that if you have a Look shared with you containing a field you don’t have an access_grant for, it will be removed from the query. It would definitely be fantastic to have a solution for that, but I can see how it’d be challenging to develop this in a way that’s clear to LookML devs and end users. I’m just starting to learn about the power of extends, so I’m going to take a stab at @IanT’s suggestion.

Ah okay… Yes we are also considering the approach with extends but having worked a lot with Salesforce I have to say I like more Permission Sets type of access but that’s just preference.

Extensions do make sense if it’s about specific groups of people and actually restricting access. To me it’s putting certain people in buckets based on their Looker experience, for example, and not confusing them with things they don’t understand but still for them to be able to run if I create a look for them.