Question

Dimensions that should be hidden in one explore but not another


Userlevel 1

Hi All,


I’m currently working on some models and explores where I want to try and reduce as much clutter in the explore as possible for the end user, whilst still allowing important fields to be accessible in drill-throughs in order to see line level detail. At the same time, some of these fields may need to be exposed in other explores.


I’ve currently been achieving this with a combination of using field/set lists in a model and duplicated dimensions e.g. application__id and application__id__hidden . However, this has a couple of problems: in the drill through data, the column has a stupid and potentially confusing name, and also it requires duplicating the dimensions which seems messy.


Is there another way of achieving this behaviour, by overriding the dimensions behaviour in the model itself?


Cheers,


Matthew


12 replies

Hi Matthew,


It sounds like you are looking for a way to define dimensions as hidden or included for explores in the model file. Unfortunately this is currently not possible but there have been requests to integrate a feature for this in the past. I will forward your case to the product team as an additional example why this would be a good idea.


Best.

Jonathan

Userlevel 1

Thanks Jonathan; yes this would be a useful feature, especially for trying to curate data for differing levels of user.

Userlevel 4

One approach might be to create a separate model per different levels of user/groups, granting Model Set access to each of the models depending on the level of user. You could then use extended Views for each of the new models, where the extended view has the same Dimensions/Measures hidden/unhidden:


view: users_extended {
extends: [users]
dimension: email {
hidden: yes
}
}

view: users {
sql_table_name: public.users ;;
dimension: email {
type: string
sql: ${TABLE}.EMAIL ;;
}
}

Or just use the fields parameter in each Model file’s Explore:


explore: users_extended {
fields: [ALL_FIELDS*,-email]
}
...

explore: users_normal {}


This will lead to a bit more development overhead which sounds cumbersome but in reality will allow you a lot more flexibility in the long run with security and permissions.

Userlevel 1

I think the problem with that is that in these scenarios we have more than one model that the same user will have access to, but we’re restricting the access for them to explore certain fields in certain models as they can be easily misconstrued there. So I think we would quite quickly end up quite a way down the rabbit hole with the number of required extended views.


For example, we have a business activity view which is tied to activity that happened on a given date, and then several progressional views that are all tied to the date a given event happened for that application. I.E. in the activity view, today this set of applications were made, this set of applications were allocated and this set of applications were completed, regardless of what date the applications were made for the latter two sets. In the progressional view, everything would be tied to the date the application was made, or the date the application was allocated, or the date the application was completed, and in these explores all other dates are not displayed as they can cause confusion and incorrect results. So the same user would need access to both explores.

Userlevel 4

@Matthew.Darwin Right yep that’s a tricky one. Currently, as Jonathan said, not really feasible within Looker, however what might be helpful is using Liquid/User Attributes to change the Dimensions/Measures labels/views for each user (check this Discourse). It won’t de-clutter the Explores but might give you some flexibility with refactoring the layout for users.


join: order_items_repurchase_facts {
view_label: "{% if _user_attributes['customer'] == 'A' %}Don't use these!
{% elsif _user_attributes['customer'] == 'B' %}To Be Deprecated
{% else %}Repurchase Facts {% endif %}"
type: left_outer


This can be done at the Dim/Measure level’s view_label too. Not perfect but might get you somewhere useful.

Userlevel 1

That does look interesting and may well help us out! Could you use a similar technique for using sets within an explore as well?

Userlevel 4

@Matthew.Darwin Unfortunately not, no. Looker won’t parse that syntax within a set or fields parameter. I was tinkering around with trying to pass in a reference by way of a parameter but no joy. Interesting thought though, I’ll file a feature request as I can definitely see some real tangible benefit from that.

Userlevel 1

Awesome! I’ll see how we get on with the use of liquid in the view/dimension labels.

Would using fields in the Explore solve your issue?


Userlevel 1

Hi Michael,


Yes as initially stated, we’re currently working around this with field lists; the problem is that if I want a particular dimension to be available in drill throughs only in one explore, and available as a selectable field for the explore in another, then we have to duplicate the dimension. If we don’t specify the dimension in the fields list, then it doesn’t appear in the drill through at all.


Cheers,


Matthew

Userlevel 2
Badge

+1 on being able to hide fields in a specific explore but not in others!

Userlevel 4

With refinements you can do that.

https://discourse.looker.com/t/organizing-your-lookml-into-layers-with-our-new-refinement-syntax/17489

Reply