Allow drilldowns to be configured and used on Embeddables in Canvas

[stacey-gammon]

It'd be great to allow users to configure drilldowns in Cavnas as well as dashboard.

I believe this would require an additional argument to be added to all the existing embeddable types - one to represent and store input.enhancements.events.

Given the push to allow users to add what is on a dashboard, to a canvas (#63303), I think we should consider supporting a generic expression function that supports any embeddable. The args would be:

• a JSON stringified representation of input and
• type

Benefits:

• Drilldowns work automatically on all embeddables in canvas
• New embeddables are automatically addable to canvas (e.g. no extra work required on ML's part to manually register a function to support the swimlane embeddable)

Cons:

• The expression string would be super ugly (could we optionally turn off expression string editing?)
• Migrations would be an issue, until the Persistable State Migrations (Persistable state migrations #63358) problem is solved.

cc @streamich @Dosant @clintandrewhall @crob611

[elasticmachine]

Pinging @elastic/kibana-canvas (Team:Canvas)

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[streamich]

My understanding is that in addition to filter issue the main issue is probably storing the drilldowns. Do I understand it correctly that in Canvas workpad embeddable visualizations are stored as an expression string with the ID of the visualization? If that is the case, we would need to figure out where to store the drilldowns attached to that visualization.

[clintandrewhall]

@streamich That's correct. Each viz type-- lens, maps, etc-- is represented by a Canvas-specific Expression function which takes the ID of the object. We did this so if, say, the Maps embeddable wanted/needed a lat/long attribute, we could add it without affecting other embeddable types, or resort to a text blob of variables.

What do you mean by "where to store drilldowns"...?

[streamich]

What do you mean by "where to store drilldowns"...?

Each drilldown has a configuration associated with it, which needs to be persisted somewhere. Say, you have a drilldown to a dashboard, it would at least store the destination dashboard ID in that config; possibly more things, in our current implementation we also store two boolean flags, whether to carry over filters and timerange, respectively.

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.