[RETIRED] Experimental Feature: Setting Up Custom Fields

(Rory O'donnell) #21

Hey this is great, but similar to merged results, if you have multiple users in that group that shouldn’t know about each other then it’s a security vulnerability b/c now they know about people in groups that don’t overlap.

For example if I have 3 different user groups that I want to bucket people in and I have a ‘experimental feature’ group that I need to bucket people into to use the new feature. I now am exposing users in these three groups to each other if they’re all part of the experimental feature. That kind of sucks. Is there a way to prevent this? Pretty sure @dgroman1988 brought up the same issue on another post I found.

(Dan Groman) #22

Yeah we experienced this and escalated to @gretchen.reyes, @Trevor_Heath and @sharon. I believe this is an item that the product team is looking into.

Can anyone confirm that?

(Izzy) #23

Hey @Rory_O_Donnell and @dgroman1988,

We’ve heard this feedback and are looking into different ways to allow access to these experimental features-- We want to make sure we’re not accidentally exposing people to experimental functionality without being absolutely sure they want to opt-in, but I hear your difficulties with getting this to mesh with a closed system.

So we can have the most context, would you rather have this be a feature that an Admin can turn on and then it’s just on for everyone, or rather have some kind of actual permission like see_custom_fields and create_custom_fields? Or, any other ideas!


(Dan Groman) #24

For context, your guys’ group implementation can accidentally expose users to groups of users who shouldn’t know about them. Beta groups shouldn’t allow other users to discover who else is on the platform.

(maanul) #25

Hi @dgroman1988, Thank you for brining this to our attention. Can you please email security@looker.com with the steps to reproduce this issue?

(Peter McCabe) #26

To include this function you need to remove the option to create a calculated field, which is understandable, however, it seems to be next to impossible to create a custom dimension or measure using the same syntax as you would a calculated field. As a result, I have tried to create numerous fields and it never works using the same syntax.

e.g. creating a custom measure using the syntax

if(${last_accessed.last_accessed_date} > ${date_filters.report_end_date}, ${date_filters.report_end_date}, ${last_accessed.last_accessed_date})

returns an error Filtered measures must have a filter expression that results in a “yesno”.

Which makes sense as it’s expecting a yes or no answer as looker is treating this as a filtered measure and not a date going by the sql generated. However, a calculated field would not behave that same way and would return a date field

Using the same logic to create a customised dimension e.g.

if(${last_accessed.last_accessed_date} > ${date_filters.report_end_date}, ${date_filters.report_end_date}, ${last_accessed.last_accessed_date})

Again, this doesn’t work because you’re creating a measure based on another measure. We can’t return a date there because the SQL wouldn’t work. If this was a caculated field then a date would be returned.

It seems the use case for this is limited so having the option for this feature vs calculated fields makes no sense as the two behave in a completely different manner. As a result, it’s another layer of complication on the tool as it’s not very intuitive.

(Ran Davidovitz) #27

What is the purpose of custom fields ? (why not simply create a dimension)?

(diego.campos) #28

Hi @Ran_Davidovitz,

Good question indeed.

Not everyone in Looker have access to LookML in order to create the dimensions they need for their Explores. Custom Fields is mostly oriented to to Business Users +, empowering their interactions with the platform.

(Brandyn Abrams) #29

Hey guys,

A little feedback after reading about this feature. I was wondering if we could set an option for users to only have access to their own custom fields versus having everyone in a group have access to these fields? I ask because it sounds great for adhoc analysis, but I worry that in a short amount of time the explores will be super crowded by these fields over time and there may be a lot of overlap if people are able to share these fields with each other?

(bernard.kavanagh) #30

Hey Brandyn,

At the moment users who can see custom fields must be part of the Custom Fields Beta Users user group.

However, it is important to note that custom fields only get saved to the looks on which they are applied, they do not get saved to an explore in that when a new user opens a fresh explore, previously saved custom fields will not be visible. So you are correct that they are used for ad-hoc analysis.

If another user creates a custom field and passes you the Explore’s URL, then you can see that custom field in the Field Picker, but not when a fresh explore is opened. Custom fields can only be shared with one another if the URL being passed has the qid parameter, eg: myinstance.looker.com/explore/ec/explore_name?qid=lEPPueGN7cHkozOEZVDQbO).

Hoping this helps!


(Cynthia Choi) #31

THANK YOU THANK YOU THANK YOU!!! This is even better than the merge queries! I’ve replaced some merge queries with custom dimensions and measures. I love that you can download the results to Excel!!! THANK YOU!!!

p.s., a CASE statement would be beyond fantabulous :slight_smile:

(Andrew Rose) #32

Hi Cynthia,

We’re glad you’re excited about custom fields! You can achieve similar functionality to a CASE statement in a custom dimension by using the “if()” Looker function: https://docs.looker.com/exploring-data/creating-looker-expressions/looker-functions-and-operators#functions_for_any_looker_expression_4

Hope this provides the functionality you were looking for!


(Cynthia Choi) #33

Yes, it’s just annoying to do a bunch of if’s but it does work :slight_smile:

(Andrew Rose) #34

Hey Cynthia,

I’ve let our product team know that you’d like a way to do this without having to use nested if statements. Have a good one!



It looks like the link to the technical documentation is to"localhost:8888". Any chance you could provide the full link?

(david.hughes) #36

Hey Suzanne,

If you replace localhost:8888 with https://docs.looker.comthis should bring you to the technical documentation.


(Izzy) #37

Link is fixed, thanks for the heads up Suzanne