Dashboards today can be parameterized by signals, which restrict the data presented on the dashboard to the subset identified by the signal. But, switching between signals is awkward in the dashboards view.
This ticket proposes to make dashboards parameterizable using signal groups. A familiar example of a signal group is "@Level":
Imagining a trivial "Event counts" dashboard, choosing to parameterize it by the "@Level" signal group would cause the "Event counts" item in the dashboard picker to become an expandable group, with "Warnings" and "Errors" variants listed below when expanded. Clicking "Warnings" would open the dashboard with the "Warnings" signal transparently applied, and clicking "Errors" would open the same dashboard with that signal used instead.
Crucially, editing the "Event counts" dashboard in either "Warnings" or "Errors" view would cause the edits to apply to both views: only one copy of the dashboard would exist behind the scenes.
Dashboards today can be parameterized by signals, which restrict the data presented on the dashboard to the subset identified by the signal. But, switching between signals is awkward in the dashboards view.
This ticket proposes to make dashboards parameterizable using signal groups. A familiar example of a signal group is "@Level":
Imagining a trivial "Event counts" dashboard, choosing to parameterize it by the "@Level" signal group would cause the "Event counts" item in the dashboard picker to become an expandable group, with "Warnings" and "Errors" variants listed below when expanded. Clicking "Warnings" would open the dashboard with the "Warnings" signal transparently applied, and clicking "Errors" would open the same dashboard with that signal used instead.
Crucially, editing the "Event counts" dashboard in either "Warnings" or "Errors" view would cause the edits to apply to both views: only one copy of the dashboard would exist behind the scenes.