You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The project involves supporting a new flyout with a holistic view on all event annotations partitioned by plugin, and then by plugin resource, for a particular visualization. To achieve this, we need to create a separate annotation line chart for each unique pluginResourceId value found in the set of events, and map them to an individual annotation line chart that will all need to be stacked on a consistent timeline.
This flyout will need to live in core Dashboards, and support logic such that any associated plugin resources that are associated with a vis can be cleanly organized and viewable in the flyout.
We will support a soft limit of 10 plugin resources per visualization. If the user changes that, scrolling may be shown in the flyout body. We will not support pagination currently.
Technical details
Opening the flyout
There are 2 ways to open the flyout - via a 'View events' button in the vis options panel, or clicking on an event point in the chart itself.
To open via 'View events' button, we can create a trigger and corresponding action using the embeddable as context, similar to the existing way actions are triggered from different menu actions.
To open by clicking on the chart, we can use the saved object ID that is passed & persisted in the chart as context.
Handling context
When the flyout opens, we want to use the same context given to the source vis embeddable (query / filters / time range), in order to render the new vis embeddables and show the same data. We can use the data plugin's queryService to do this, which fetches the global context.
Handling refresh
By default, we don't want to have the charts auto-refresh in the flyout (if enabled at the dashboard level). We can manually turn this off by calling updateInput() on the embeddable with an updated refreshConfig. If the user wants to do a manual refresh, we have a button at the top of the flyout where, when clicked, calls reload() on each visible embeddable.
Fetching VisLayers
Given some embeddable, we need to be able to access its latest set of VisLayers so the flyout can process them accordingly. To do this, we can add a visLayers field in the visualize embeddable. It can be set in updateHandler(), which is triggered upon any input changes to the embeddable where they are initially fetched.
Generating VisLayer embeddable charts
We can easily generate the source vis embeddable by creating a new one from its saved object ID and passing in the identical global context, as mentioned above. To generate the individual charts below (one per VisLayer), we need to pull out individual time series data and display them in separate charts.
Because there is no easy way to extract the source datatable from the source vis embeddable to filter out data and generate a new chart, we need to find a different way. If we take on the perspective that each VisLayer chart is the same as the source chart but just with filtered data, this makes things simpler. We can introduce a new optional visLayerResourceIds field in the visualize embeddable, such that we will only show events / layers that are coming from the set of visLayerResourceIds. In the context of this flyout, we can just re-generate an embeddable for each VisLayer, passing in a single visLayerResourceId.
This gives us a very flexible advantage and opens the door for many interesting ways we may want to overlay data on the charts in the future, such as being able to toggle on/off all events coming from one particular plugin, or a subset of plugins, or a subset within a plugin, etc.
Adding fields to the VisLayer
There is some additional fields we need to persist within a VisLayer to properly render the flyout. This includes the resource name, url, and resource type. Those are added separately as part of #3374.
Example mockup (not finalized):
Open questions: 1. Should there be a default limit on the number of resources viewable? 2. If no limit, how should scrolling and/or searching be handled to access all potential plugin resource line charts?
The text was updated successfully, but these errors were encountered:
Overview
Coming from #2880
The project involves supporting a new flyout with a holistic view on all event annotations partitioned by plugin, and then by plugin resource, for a particular visualization. To achieve this, we need to create a separate annotation line chart for each unique
pluginResourceId
value found in the set of events, and map them to an individual annotation line chart that will all need to be stacked on a consistent timeline.This flyout will need to live in core Dashboards, and support logic such that any associated plugin resources that are associated with a vis can be cleanly organized and viewable in the flyout.
We will support a soft limit of 10 plugin resources per visualization. If the user changes that, scrolling may be shown in the flyout body. We will not support pagination currently.
Technical details
Opening the flyout
There are 2 ways to open the flyout - via a 'View events' button in the vis options panel, or clicking on an event point in the chart itself.
To open via 'View events' button, we can create a trigger and corresponding action using the embeddable as context, similar to the existing way actions are triggered from different menu actions.
To open by clicking on the chart, we can use the saved object ID that is passed & persisted in the chart as context.
Handling context
When the flyout opens, we want to use the same context given to the source vis embeddable (query / filters / time range), in order to render the new vis embeddables and show the same data. We can use the data plugin's
queryService
to do this, which fetches the global context.Handling refresh
By default, we don't want to have the charts auto-refresh in the flyout (if enabled at the dashboard level). We can manually turn this off by calling
updateInput()
on the embeddable with an updatedrefreshConfig
. If the user wants to do a manual refresh, we have a button at the top of the flyout where, when clicked, callsreload()
on each visible embeddable.Fetching
VisLayer
sGiven some embeddable, we need to be able to access its latest set of
VisLayer
s so the flyout can process them accordingly. To do this, we can add avisLayers
field in the visualize embeddable. It can be set inupdateHandler()
, which is triggered upon any input changes to the embeddable where they are initially fetched.Generating
VisLayer
embeddable chartsWe can easily generate the source vis embeddable by creating a new one from its saved object ID and passing in the identical global context, as mentioned above. To generate the individual charts below (one per
VisLayer
), we need to pull out individual time series data and display them in separate charts.Because there is no easy way to extract the source datatable from the source vis embeddable to filter out data and generate a new chart, we need to find a different way. If we take on the perspective that each
VisLayer
chart is the same as the source chart but just with filtered data, this makes things simpler. We can introduce a new optionalvisLayerResourceIds
field in the visualize embeddable, such that we will only show events / layers that are coming from the set ofvisLayerResourceIds
. In the context of this flyout, we can just re-generate an embeddable for eachVisLayer
, passing in a singlevisLayerResourceId
.This gives us a very flexible advantage and opens the door for many interesting ways we may want to overlay data on the charts in the future, such as being able to toggle on/off all events coming from one particular plugin, or a subset of plugins, or a subset within a plugin, etc.
Adding fields to the
VisLayer
There is some additional fields we need to persist within a
VisLayer
to properly render the flyout. This includes the resource name, url, and resource type. Those are added separately as part of #3374.Example mockup (not finalized):
Open questions:1. Should there be a default limit on the number of resources viewable?2. If no limit, how should scrolling and/or searching be handled to access all potential plugin resource line charts?The text was updated successfully, but these errors were encountered: