Ability to include extra attributes or entire object when drilling


Currently, when using the `onDrill` in the GD-UI, you can define which headers and attributes are drillable.  The `onDrill` callback however returns the measures and attributes used in the chart.  It’d be useful to be able to define other attributes to be returned or returning the entire entity for the drillable item would suffice as well.

This is useful for returning attributes for further processing or lookups without exposing additional information to the end user.  For example, the name of an entity is more useful than an ID for the end user, for a developer though, returning the ID is more useful than the name.  This also saves a step from having to do a lookup by a potentially non-unique string.

Hi @hpatskan I am not sure I understand what you would like to achieve. In the object passed to the onDrill callback, you can access all the information not only about what was actually clicked, but also about the rest of the execution (see the API reference for the value). There are two properties:

  • drillContext that tells you about the particular interaction (i.e. what exactly was clicked by the user)
  • dataView that contains information about the execution used to drive the visualisation (including the definition, results, and more), see the API reference of its type

These two should give you what you need to handle the drill event the way you want.

Or is there something I misunderstood from your question? 🙂


Hey @Dan Homola,

Maybe this can help give you more context: https://gooddataconnect.slack.com/archives/C01UR5BGAHY/p1662045551454379.

The issue we’re having though is, on drillDown, only the values, labels used to create the query are returned.  What we’d like to be able to do is also include additional attributes for each entity.

So for example, if i have a chart where the chart is sliced by project name, when i click on drill down, i get the project name, label name and datapoint.  What i’d also like to do is also include the project ID as well so i don’t have to do a lookup on my end by name.

Thanks,


Thanks for the additional info, it is clearer now!

Just to make sure we are really on the same page: you would like to receive the value of an alternate label to the one actually used to run the execution. For example:

You have an attribute Project and it has two labels: ProjectID and ProjectName. You then have a visualization that uses ProjectName to display something and in the onDrill event you would like to also receive the relevant value of the ProjectID (in addition to the value of ProjectName you are already getting) but not show it in the visualisation anywhere.

Is that correct?


@Dan Homola,

Ideally, what i’d like to be able to do, is for each entity in the chart, i could append additional hidden properties.

Let’s say i have a “Project” entity with the following properties:

  • ID
  • Name
  • Description
  • Owner ID
  • Created Date Time

In a bar chart:

  • Metrics
    • metric_1
    • metric_2
    • metric_3
  • View By
    • Name
  • OnDrill include
    • ID
    • Name
    • Owner ID
    • metric_1 value
    • metric_2 value
    • metric_3 value

I tried adding additional labels and hiding them but unfortunately it didn’t work out well and caused issues in the numbers i think.  This is probably quite a bit of work though, so what you suggested could be a good quick solution also so long as it doesn’t create additional slices in the data.  This would save me the additional work of doing a lookup by “Name” which may not be unique.

 

Thanks,


Hi @hpatskan,

I am still not sure about the solution you would prefer. I am not sure we could do it without the extra slices: we need to see which value of an attribute “belongs” to which data point (for the drilling to make sense) so we have to slice by it I’m afraid. And we cannot “merge” these extra slices on the client because the aggregation used might not be associative (e.g. avg) so only the execution can tell us the correct number.

Or am I still missing something?


@Dan Homola 

Understood, i thought this might be a bit of a stretch since they’d have to be done by slices, i think your approach with hiding a slice could work though as long as i’m careful with the attributes.