Skip to content

feat(dashboards): Support linked dashboards in timeseries widgets#111078

Merged
DominikB2014 merged 5 commits intomasterfrom
dominikbuszowiecki/browse-448-support-linked-dashboards-in-timeseries-widgets
Mar 19, 2026
Merged

feat(dashboards): Support linked dashboards in timeseries widgets#111078
DominikB2014 merged 5 commits intomasterfrom
dominikbuszowiecki/browse-448-support-linked-dashboards-in-timeseries-widgets

Conversation

@DominikB2014
Copy link
Contributor

@DominikB2014 DominikB2014 commented Mar 19, 2026

Adds support for setting linkedDashboards on groupBy columns in timeseries widgets when using breakdown legend type. Previously, linked dashboards were only configurable for table widgets.

The timeseries visualization already rendered linked dashboard URLs in the breakdown legend footer, but there was no way to configure them through the widget builder for non-table widgets.

Changes:

  • Add "Link field" button to groupBy selector rows (only visible when legend type is breakdown and drilldown flows feature is enabled)
  • Allow SET_LINKED_DASHBOARDS action for breakdown legend type in addition to table display type
  • Clear linkedDashboards when legend type changes away from breakdown
  • Deduplicate linked dashboard entries when re-linking a field that already has a linked dashboard
  • Add renderExtraActions prop to QueryField and GroupBySelector for extensibility
image image image

Allow setting linkedDashboards on groupBy columns for timeseries widgets
with breakdown legend type. Previously only table widgets supported this.

- Add link button to groupBy selector when legend type is breakdown
- Allow SET_LINKED_DASHBOARDS for breakdown legend type, not just tables
- Clear linkedDashboards when legend type changes away from breakdown
- Populate linkedDashboards in widget builder when editing existing widgets
- Handle linkedDashboards in SET_STATE action and URL query params

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@linear-code
Copy link

linear-code bot commented Mar 19, 2026

@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Mar 19, 2026
…111085

Remove linkedDashboards query param, SET_DATASET handler, and
serializeLinkedDashboards export that duplicate changes in PR #111085.

Co-Authored-By: Claude Opus 4.6 <noreply@example.com>
@DominikB2014
Copy link
Contributor Author

@cursor review

Copy link
Contributor

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Filter out existing entries for the same field before appending
the new linked dashboard, preventing duplicate entries when a user
re-links a field that already has a linked dashboard.

Co-Authored-By: Claude Opus 4.6 <noreply@example.com>
@DominikB2014 DominikB2014 marked this pull request as ready for review March 19, 2026 17:03
@DominikB2014 DominikB2014 requested a review from a team as a code owner March 19, 2026 17:03
Copy link
Member

@narsaynorath narsaynorath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small comment about renderExtraActions, it's not a big deal but worth considering a cleanup for if you don't want to block this PR on it

canDrag={canDrag}
canDelete={canDelete}
disabled={disable}
renderExtraActions={renderExtraActions?.(column, index)}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to provide the index if the newest instance of this doesn't require it, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And instead of passing down this function.. Would it be better to just compose extra actions as a component and pass that component down? Or maybe if you need all the scope and don't want to drill it down, possibly consider a component where this renderExtraActions is defined?

I've heard of it's a possible performance issue, I found this article on it but maybe there are others discussing it better: https://playfulprogramming.com/posts/functions-are-killing-react-performance/#render-functions

Copy link
Contributor Author

@DominikB2014 DominikB2014 Mar 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, a prop for a component is better, i'll make that change! I'll do it in a followup

@DominikB2014 DominikB2014 merged commit a569376 into master Mar 19, 2026
67 checks passed
@DominikB2014 DominikB2014 deleted the dominikbuszowiecki/browse-448-support-linked-dashboards-in-timeseries-widgets branch March 19, 2026 18:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Frontend Automatically applied to PRs that change frontend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants