URL drilldown

[streamich]

URL Drilldown MVP

• Add license support for drilldowns (and actions). Dynamic uiActions & license support #68507
• Basic nested triggers support ([Ui Actions] Support emitting nested triggers and actions #59162)
• Provide trigger info on action execution context ([Discuss] Trigger context interface #63854) (nice to have)
• MVP of URL drilldown with simple <textarea> as input (Embeddable to URL) . [wip] URL drilldown #68235 POC URL drilldown: trigger picker #70421
• Use URL drilldown to navigate to different Kibana apps.
• Add user facing docs for elastic.co website.

Next

• URL editor helpers
• URL encoding
• URL editor improvements
• URL allow-list

Vague ideas & backlog

• Helpers for Handlebars conditional functions, to use in #if statement.
• URL drilldown templates
• Better previews and validation
• SSO.
• Access variables from underlying documents
• Extension points
• Fixed user edited list of variables available in the URL?

Notes

Currently dashboard state (including drilldown state) in edit mode is synced to browser URL. For URL drilldown project we agreed it is OK to use this existing functionality, it is up to KibanaApp team to decide if they want to remove state from the URL in the future.

We also agreed not to build external URL allow-list specifically for the URL drilldown, but in the future Kibana will have a allow-list with which URL drilldown will integrate.

Part of #42845 #61785

[elasticmachine]

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

[Dosant]

Had a thought during meeting:

We have build-stats and gitHub-stats kibana instances.
Would be great if we could validate our solution using those real world use case Kibanas by building drilldowns to GitHub and to Jenkins

Example GitHub url were we could drilldown to issue list of a team: https://github.com/elastic/kibana/issues?q=is%3Aopen+is%3Aissue+label%3ATeam%3A${team}

[Dosant]

@streamich, wonder what do you meant by "phase"?

• Development phase where we shouldn't move to next "phase" until done with previous?
• Or feature "phase" where we could merge to master and allow using feature after each phase?

My confusion is that: this feature won't go live without phase 1-4 implemented, but phase 5 (sso) is an improvement on top?

So what do you think of moving phase 5 (sso) to different issue and not touch it at all for now? (This was my impression after last drilldowns sync meeting)