Dashboard drilldowns are not using saved object references

[timroes]

When currently storing a dashboard drilldown on a panel, the config inside the panels object in the dashboard saved object will look like:

dynamicActions": {
  "events": [
    {
      "eventId": "c2363b35-045c-4d25-979e-cb9703f002db",
      "triggers": [
        "VALUE_CLICK_TRIGGER",
        "SELECT_RANGE_TRIGGER"
      ],
      "action": {
        "name": "iuyhgft",
        "config": {
          "dashboardId": "edf84fe0-e1a0-11e7-b6d5-4dc382ef7f5b",
          "useCurrentFilters": true,
          "useCurrentDateRange": true
        },
        "factoryId": "DASHBOARD_TO_DASHBOARD_DRILLDOWN"
      }
    }
  ]
}

The drilldown contains a dashboardId directly instead of using the saved object reference system for it and properly stored the link to the saved object in the reference part of the saved object. This means those drilldowns will all break when the saved objects would change their ids (currently planned for the sharing between spaces feature).

We need to change this behavior and migrate all existing drilldown saved objects to use references correctly.

cc @ppisljar @alexh97 and @legrego (sorry this seems to be another (new) blocker).

Part of #42845

---

@Dosant:

[2020-10-19] An update on this:

• Implemented inject/extract functionality on dashboard drilldown in [wip] Dashboard drilldown SO references #80832 on top of Embeddable telemetry and reference extraction/injection #74352 - looks good
  • Discovered that SO cyclic references are not fully supported. Some features are broken. * Created separate issue to discuss and tackle this: Support for cyclic SO references #80966
  • [wip] Dashboard drilldown SO references #80832 needs to migrate all older drilldowns to use references. This is blocked by Embeddable persistable state migration #80973, which bumps into issue that with current approach we need to somehow register a SO migration in START phase: Embeddable persistable state migration #80973 (comment)
• Parking further work on [wip] Dashboard drilldown SO references #80832 until have a path forward with issues above

[elasticmachine]

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

[legrego]

Thanks for the ping @timroes. I think this is blocking phase 3 of sharing saved objects, since drilldowns are always(?) referencing dashboards, and not say, index patterns.

Phase 2 (our next phase) is concerned with sharing saved objects which themselves don't have references (such as index patterns).

So, this is something we absolutely need fixed, but it's not as high of a priority as #59960, which is blocking Phase 2 of our work.

cc @jportner

[streamich]

To fix this we will need the dashboard plugin to provide a way to update references and then we will need to add APIs to embeddable which will allow to update references when input changes.

We should also discuss if we/how we want to store the references for drilldown saved objects; as storing the references would mean that when object is copied to another space all other saved objects it references are also copied to that space, AFAIK. Meaning if a dashboard has drilldowns to few other dashboard and we store references for those, those other dashboards will also get copied to the new space together with the source dashboard.

[ppisljar]

this is blocked by #67931

[streamich]

also blocked by #71431

[Dosant]

Started working on this on top of #71431.

Q: Are cyclic references allowed? Seems like no?
It is a completely valid use case to link dashboard with drilldowns in the following way:
DashboardA -> DashboardB -> DashboardA

What would be a recommended approach for handling such references?

[mshustov]

@Dosant Could you elaborate how do you model data storage? Does reference chain look like
DashboardA ---> DrilldownA ---> Dashboard B ---> DrilldownB ---> DashboardA ?

[Dosant]

@restrry,
Drilldown is not an SO. In the end it is just serialized into dashboard SO inside the dashboard panels. panelsJSON
So from SO perspective data storage is literally: DashboardA -> DashboardB -> DashboardA

[ppisljar]

@Dosant from dashboards perspective, its just extracting references, where one of them might point to another dashboard. it doesn't care if that other dashboard points back to it. But you are right we'll need to make sure any logic using this references is good enough so it doesn't break under cyclic reference. But from user experience perspective i don't see an issue. if i have Dashboard A->Dashboard B->Dashboard A ... when i copy dashboard A to new space dashboard B will be copied with it. And if i copy dashboard B, dashboard A will be copied with it. all good.

[Dosant]

An update on this:

• Implemented inject/extract functionality on dashboard drilldown in [wip] Dashboard drilldown SO references #80832 on top of Embeddable telemetry and reference extraction/injection #74352 - looks good
  • Discovered that SO cyclic references are not fully supported. Some features are broken. Created separate issue to discuss and tackle this: Support for cyclic SO references #80966
  • [wip] Dashboard drilldown SO references #80832 needs to migrate all older drilldowns to use references. This is blocked by Embeddable persistable state migration #80973, which bumps into issue that with current approach we need to somehow register a SO migration in START phase: Embeddable persistable state migration #80973 (comment)
• Parking further work on [wip] Dashboard drilldown SO references #80832 until have a path forward with issues above

[Dosant]

Checked that with the #80966 the export and copy to space part works as expected 🙌
To continue, need to address #80973 (cc @ppisljar) Actually we are good. Don't need migrate function on embeddables for this.