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!

Best,
Izzy


(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.