[Exploatory view] Fix duplicate breakdowns

[shahzad31]

Summary

Fixes #117032

Remove breakdown from clones series, when user tries to copy a series

After:

Before:

[dominiqueclarke]

We had actually discussed a while back with @drewpost and @liciavale not using the series name for the breakdown labels, because then you lose context of the actual metric type. What do you think @drewpost @liciavale? What would you prefer?

[drewpost]

I'm not sure I remember that conversation. (entirely possible with my Swiss Cheese brain). The preferred behaviour is that the legend matches the series name

[dominiqueclarke]

I'm not sure I remember that conversation. (entirely possible with my Swiss Cheese brain). The preferred behaviour is that the legend matches the series name

@drewpost The problem I see is that, for the chart itself, there is no longer any context of the data type for series. When isolating the chart away from the series, you can see the issue

Of course, you can see the metric type when referring back to the corresponding series.

Happy to implement it either way, just raising my concerns.

[shahzad31]

I'm not sure I remember that conversation. (entirely possible with my Swiss Cheese brain). The preferred behaviour is that the legend matches the series name

@drewpost The problem I see is that, for the chart itself, there is no longer any context of the data type for series. When isolating the chart away from the series, you can see the issue

Of course, you can see the metric type when referring back to the corresponding series.

Happy to implement it either way, just raising my concerns.

@dominiqueclarke my suggestion would be to include metric instead of data type in default naming, like instead of saying ux-series, we could say page-views series, and at that point it's up to the user to come up with a better name. WDYT?

[shahzad31]

@elasticmachine merge upstream

[dominiqueclarke]

I'm not sure I remember that conversation. (entirely possible with my Swiss Cheese brain). The preferred behaviour is that the legend matches the series name

@drewpost The problem I see is that, for the chart itself, there is no longer any context of the data type for series. When isolating the chart away from the series, you can see the issue

Of course, you can see the metric type when referring back to the corresponding series.
Happy to implement it either way, just raising my concerns.

@dominiqueclarke my suggestion would be to include metric instead of data type in default naming, like instead of saying ux-series, we could say page-views series, and at that point it's up to the user to come up with a better name. WDYT?

We could also append the metric, like say ux-series-page-views/ux-series-2-page-views. Or page-views-ux-series.

I think it could be nice to also have the data type in the default name, but then with longer names it's more possible to get cut off.

[kibanamachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 9974a15
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
observability	378.7KB	378.8KB	+17.0B

History

• 💚 Build #4636 succeeded 9b7983e
• 💚 Build #3953 succeeded f196329

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @shahzad31

[dominiqueclarke]

LGTM. Only one breakdown being applied at a time when series is copied.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 117304 or prevent reminders by adding the backport:skip label.

[kibanamachine]

The following labels were identified as gaps in your version labels and will be added automatically:

• v8.1.0

If any of these should not be on your pull request, please manually remove them.

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	8.0
✅	7.16

The backport PRs will be merged automatically after passing CI.