Conditional hiding of groups, dimensions, measures

(Dawid) #1

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…


Access grant - bug?
(Ben Silverstein) #2

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.


Access grant - bug?
(Dawid) #3

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

Mod please move these comments here:


(Izzy) #4


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…


(Ben Silverstein) #5

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.


(Dawid) #6

I heard that some people use a conditional statement in the hidden field based on user attribute like hidden: = <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.


(Izzy) #7

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!


(Dawid) #8

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


(Ian) #9

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.

1 Like

(Dawid) #10

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


(Ian) #11

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