Applying dynamic filters on Links as Drilldowns

spolo
New Member

Using the [drill_fields] feature to apply a Drill Down into the data is great but it’s missing some key features that my company needed that I thought I resolved that using [link] instead.  

2 features that we needed to resolve was A) the ability to sort the explore data and B) the ability to have different sets of drilldown fields depending on what the end user would like to pull out to investigate.

The later is extremely important to us especially when we have several different types of Dashboards hitting the same LookML code.  Instead of creating one massively long set field that captures a very wide extract, we needed to break them down and label them with their distinct tasks.

Again, I thought I solved this with the following code in which I actually supplied in the following post as well to share with others
 

https://community.looker.com/dashboards-looks-7/drill-down-with-multiple-choice-5557

measure: count {
    type: count
    value_format: "#,##0"
    link: {
      label: "COMBO 1 DRILLDOWN"
      url: "/explore/SPOKE_NAME/VIEW_NAME?fields=VIEW_NAME.DRILL_FIELD_COMBO_1*"
    }
    link: {
      label: "COMBO 2 DRILLDOWN"
      url: "/explore/SPOKE_NAME/VIEW_NAME?fields=VIEW_NAME.DRILL_FIELD_COMBO_2*"
    }
    view_label: "Base Data"
    label: "Count"
  }


  set: DRILL_FIELD_COMBO_1{
    fields: [
      FIELD_1
      ,FIELD_2
      ,FIELD_3
    ]
  }


  set: DRILL_FIELD_COMBO_2{
    fields: [
      FIELD_1
      ,FIELD_4
      ,FIELD_5
    ]
  }

Unfortunately we just discovered a massive flaw with this approach.  Using the link feature, it does not scope in the filters that are being applied on the table when it’s invoked.  Instead it lifts the entire unfiltered dataset from the LookML code unlike how [drill_fields] work.  After some googling, it seems the only solution would be to explicitly write in filter functionality for each and every filter like so

&f[view_name.field_name]={{ _filters['view_name.field_name'] | url_encode }}

This doesn’t work for us for several reasons.  First anytime a new filter is added to a dash, you would to go through all these links to make sure that the filter is being applied there as well.  Secondly and most important, each Dashboard and each table within each Dashboard may have a complete different set of filters applied that [drill_fields] would be smart enough to scope out.  

So this simply does not work for us.  Is there a way to add some logic that will apply filtering based on the scope of where it was invoked dynamically like [drill_fields] do or is that not possible?  Does this need to be an enhancement?  

2 5 3,309
5 REPLIES 5
Top Labels in this Space
Top Solution Authors