[Lens] Fix coloring/palette assignment on partition charts

[nickofthyme]

Summary

Fixes an issue where reordering the groups within a layer would incorrectly assign the color mapping to a group other than the first.

Zight.Recording.2025-03-20.at.05.44.41.PM.mp4

Fixes #203178

release_note: Fixes issue with color mapping when reordering groups in partition charts.

Details

The issue here was due to the order of the columns. The colorMapping prop is applied at the layer so we need to find the first non-collapsed group to take "ownership" of the color mapping config. Previously we used layer.primaryGroups as the order but this could be incorrect when reordering groups.

We can correct this by relying on the column order from the datasource using the getSortedAccessorsForGroup utility.

This issue applied to both the group display properties that control the appearance of the group in the editor, and the Color mapping row within the editor.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[markov00]

@dej611 @nickofthyme I've checked the code and the fix works correctly. But I have a doubt: we are keeping the column order in two places: one at the datasourceState level in the columnOrder and another within the primaryGroups and secondaryGroups.
The usage of these primary and secondary groups are the following (from what I've understood):

• keep track of the order of the column ids associated to the layer and to each group.
• the secondary group is only used in the mosaic chart where we visually split in vertical/horizontal splits the data.
• the order we aggregate the data is important because represent how each partition layer is defined: we have 0 or more partition layers (called groups) and the final aggregation is the metric.
• in a pie/treemap the order is always defined by the aggregation order, so the data is driven by that columnOrder in the datasource and not by the primaryGroups sorting order (with the last column referring always to the metric)
• in the mosaic the first partition layer/group is always the vertical axis, the second always the horizontal, and the last is the metric.

With that I'm wondering why we need to have these properties primaryGroups and secondaryGroups instead of just relying to the datasource columnOrder, that is actually what Nick have done by using the getSortedAccessorsForGroup

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 9c6c4da

Failed CI Steps

• FTR Configs #66
• FTR Configs #107

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
lens	1.4MB	1.4MB	-24.0B

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/14115122282

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation