[ColorMapping] Store assignments as raw/serialized values#207957
Merged
nickofthyme merged 93 commits intoelastic:mainfrom May 5, 2025
Merged
[ColorMapping] Store assignments as raw/serialized values#207957nickofthyme merged 93 commits intoelastic:mainfrom
nickofthyme merged 93 commits intoelastic:mainfrom
Conversation
- use stringified categories for legacy palettes - pass formatter to all color mapping usages - cleanup new color mapping toggle logic - only compute categories when color mapping is enabled
…lastic#208623 - only handle untransposed data to collate categories - use untransposed data in lens datatable renderer - updates usages of getColorCategories
- match with or without formatting - match rule should only match full values
- removes looping over assignments - removes nested n squared loops to find corresponding assignment - create class to abstract and centralize logic
markov00
reviewed
Mar 11, 2025
src/platform/packages/shared/kbn-coloring/src/shared_components/color_mapping/README.md
Show resolved
Hide resolved
x-pack/platform/plugins/shared/lens/common/expressions/datatable/utils.ts
Outdated
Show resolved
Hide resolved
...atform/plugins/shared/lens/public/visualizations/xy/runtime_state/converters/legend_stats.ts
Outdated
Show resolved
Hide resolved
.../plugins/shared/lens/public/visualizations/xy/runtime_state/converters/raw_color_mappings.ts
Outdated
Show resolved
Hide resolved
.../plugins/shared/lens/public/visualizations/xy/runtime_state/converters/raw_color_mappings.ts
Outdated
Show resolved
Hide resolved
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
8 similar comments
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
2 tasks
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
1 similar comment
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
5 tasks
Contributor
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Contributor
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
Contributor
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
1 similar comment
Contributor
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
akowalska622
pushed a commit
to akowalska622/kibana
that referenced
this pull request
May 29, 2025
…7957) ## Summary Refactors color mapping logic to store raw values in save objects. Main changes: - Instead assignments having a single rule with many values, we now have assignments with multiple rules of varying types with a single value. - As per the previous change, there is no more explicit `auto` rule, this is now implicit when there are no rules in the assignment. - Raw values can now be raw and in cases such as `RangeKey`s and `MultiValueKey`s can be instance values. This is not ok for storing in redux nor the SO so be have added a `serialize` methods to facilitate this value storage. Code changes attempt to identify which value is used based on variable/param names and type aliases as both are `unknown`. - For values that are non-string or non-number types, we no longer allow creating custom matching options. - Values are now correctly formatted. - Add runtime migration for `xy`, `partition`, `tagcloud` and `datatable` viz. Requires `formBased` `datasourceState` to determine best string-to-raw value convertion. Closes elastic#193080 Fixes elastic#187519 ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] 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. - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks <!-- Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging --> - [x] Migration from previous stored types. ## Release note This PR fixes an issue ([elastic#193080](elastic#193080)) where custom ranges and multi-field values were not correctly colored based on selected color mapping configurations. This change includes a runtime migration to convert old mappings as strings to their raw value equivalent. This conversion is done at runtime when the vis is rendered and only updated when the visualization is saved. Thus this conversion does not dirty the state of the visualization such as when first opening to edit. This _should_ have no affect to the user apart from improved value formatting in the color mapping assignment selection UI. In rare cases, some assignments may not be correctly converted exactly to the new raw value but are still preserved to use as string value matches. The only know case where we are not be able to fully convert the value is when using labels on custom ranges, the label will not show in the color mapping assignment UI unless the value is removed as added back. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com> Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
Contributor
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Contributor
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
nickofthyme
added a commit
to nickofthyme/kibana
that referenced
this pull request
Jun 2, 2025
…7957) Refactors color mapping logic to store raw values in save objects. Main changes: - Instead assignments having a single rule with many values, we now have assignments with multiple rules of varying types with a single value. - As per the previous change, there is no more explicit `auto` rule, this is now implicit when there are no rules in the assignment. - Raw values can now be raw and in cases such as `RangeKey`s and `MultiValueKey`s can be instance values. This is not ok for storing in redux nor the SO so be have added a `serialize` methods to facilitate this value storage. Code changes attempt to identify which value is used based on variable/param names and type aliases as both are `unknown`. - For values that are non-string or non-number types, we no longer allow creating custom matching options. - Values are now correctly formatted. - Add runtime migration for `xy`, `partition`, `tagcloud` and `datatable` viz. Requires `formBased` `datasourceState` to determine best string-to-raw value convertion. Closes elastic#193080 Fixes elastic#187519 - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] 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. - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) <!-- Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging --> - [x] Migration from previous stored types. This PR fixes an issue ([elastic#193080](elastic#193080)) where custom ranges and multi-field values were not correctly colored based on selected color mapping configurations. This change includes a runtime migration to convert old mappings as strings to their raw value equivalent. This conversion is done at runtime when the vis is rendered and only updated when the visualization is saved. Thus this conversion does not dirty the state of the visualization such as when first opening to edit. This _should_ have no affect to the user apart from improved value formatting in the color mapping assignment selection UI. In rare cases, some assignments may not be correctly converted exactly to the new raw value but are still preserved to use as string value matches. The only know case where we are not be able to fully convert the value is when using labels on custom ranges, the label will not show in the color mapping assignment UI unless the value is removed as added back. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com> Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
Contributor
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
qn895
pushed a commit
to qn895/kibana
that referenced
this pull request
Jun 3, 2025
…7957) ## Summary Refactors color mapping logic to store raw values in save objects. Main changes: - Instead assignments having a single rule with many values, we now have assignments with multiple rules of varying types with a single value. - As per the previous change, there is no more explicit `auto` rule, this is now implicit when there are no rules in the assignment. - Raw values can now be raw and in cases such as `RangeKey`s and `MultiValueKey`s can be instance values. This is not ok for storing in redux nor the SO so be have added a `serialize` methods to facilitate this value storage. Code changes attempt to identify which value is used based on variable/param names and type aliases as both are `unknown`. - For values that are non-string or non-number types, we no longer allow creating custom matching options. - Values are now correctly formatted. - Add runtime migration for `xy`, `partition`, `tagcloud` and `datatable` viz. Requires `formBased` `datasourceState` to determine best string-to-raw value convertion. Closes elastic#193080 Fixes elastic#187519 ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] 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. - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks <!-- Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging --> - [x] Migration from previous stored types. ## Release note This PR fixes an issue ([elastic#193080](elastic#193080)) where custom ranges and multi-field values were not correctly colored based on selected color mapping configurations. This change includes a runtime migration to convert old mappings as strings to their raw value equivalent. This conversion is done at runtime when the vis is rendered and only updated when the visualization is saved. Thus this conversion does not dirty the state of the visualization such as when first opening to edit. This _should_ have no affect to the user apart from improved value formatting in the color mapping assignment selection UI. In rare cases, some assignments may not be correctly converted exactly to the new raw value but are still preserved to use as string value matches. The only know case where we are not be able to fully convert the value is when using labels on custom ranges, the label will not show in the color mapping assignment UI unless the value is removed as added back. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com> Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
nickofthyme
added a commit
that referenced
this pull request
Jun 3, 2025
…7957) (#221704) # Backport This will backport the following commits from `main` to `8.19`: - [[ColorMapping] Store assignments as raw/serialized values (#207957)](#207957) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Nick Partridge","email":"nicholas.partridge@elastic.co"},"sourceCommit":{"committedDate":"2025-05-05T23:20:11Z","message":"[ColorMapping] Store assignments as raw/serialized values (#207957)\n\n## Summary\n\nRefactors color mapping logic to store raw values in save objects.\n\nMain changes:\n\n- Instead assignments having a single rule with many values, we now have\nassignments with multiple rules of varying types with a single value.\n- As per the previous change, there is no more explicit `auto` rule,\nthis is now implicit when there are no rules in the assignment.\n- Raw values can now be raw and in cases such as `RangeKey`s and\n`MultiValueKey`s can be instance values. This is not ok for storing in\nredux nor the SO so be have added a `serialize` methods to facilitate\nthis value storage. Code changes attempt to identify which value is used\nbased on variable/param names and type aliases as both are `unknown`.\n- For values that are non-string or non-number types, we no longer allow\ncreating custom matching options.\n- Values are now correctly formatted.\n- Add runtime migration for `xy`, `partition`, `tagcloud` and\n`datatable` viz. Requires `formBased` `datasourceState` to determine\nbest string-to-raw value convertion.\n\nCloses #193080\nFixes #187519\n\n### Checklist\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\n- [x]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas added for features that require explanation or tutorials\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [x] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n### Identify risks\n\n\n\n- [x] Migration from previous stored types.\n\n## Release note\n\nThis PR fixes an issue\n([#193080](#193080)) where\ncustom ranges and multi-field values were not correctly colored based on\nselected color mapping configurations.\n\nThis change includes a runtime migration to convert old mappings as\nstrings to their raw value equivalent. This conversion is done at\nruntime when the vis is rendered and only updated when the visualization\nis saved. Thus this conversion does not dirty the state of the\nvisualization such as when first opening to edit.\n\nThis _should_ have no affect to the user apart from improved value\nformatting in the color mapping assignment selection UI. In rare cases,\nsome assignments may not be correctly converted exactly to the new raw\nvalue but are still preserved to use as string value matches. The only\nknow case where we are not be able to fully convert the value is when\nusing labels on custom ranges, the label will not show in the color\nmapping assignment UI unless the value is removed as added back.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Marco Liberati <dej611@users.noreply.github.com>\nCo-authored-by: Marco Vettorello <marco.vettorello@elastic.co>","sha":"fa1512572c0467bc3b3c4b637db69b394302cd00","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Visualizations","Feature:Lens","backport missing","backport:version","v9.1.0","v8.19.0"],"title":"[ColorMapping] Store assignments as raw/serialized values","number":207957,"url":"https://github.com/elastic/kibana/pull/207957","mergeCommit":{"message":"[ColorMapping] Store assignments as raw/serialized values (#207957)\n\n## Summary\n\nRefactors color mapping logic to store raw values in save objects.\n\nMain changes:\n\n- Instead assignments having a single rule with many values, we now have\nassignments with multiple rules of varying types with a single value.\n- As per the previous change, there is no more explicit `auto` rule,\nthis is now implicit when there are no rules in the assignment.\n- Raw values can now be raw and in cases such as `RangeKey`s and\n`MultiValueKey`s can be instance values. This is not ok for storing in\nredux nor the SO so be have added a `serialize` methods to facilitate\nthis value storage. Code changes attempt to identify which value is used\nbased on variable/param names and type aliases as both are `unknown`.\n- For values that are non-string or non-number types, we no longer allow\ncreating custom matching options.\n- Values are now correctly formatted.\n- Add runtime migration for `xy`, `partition`, `tagcloud` and\n`datatable` viz. Requires `formBased` `datasourceState` to determine\nbest string-to-raw value convertion.\n\nCloses #193080\nFixes #187519\n\n### Checklist\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\n- [x]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas added for features that require explanation or tutorials\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [x] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n### Identify risks\n\n\n\n- [x] Migration from previous stored types.\n\n## Release note\n\nThis PR fixes an issue\n([#193080](#193080)) where\ncustom ranges and multi-field values were not correctly colored based on\nselected color mapping configurations.\n\nThis change includes a runtime migration to convert old mappings as\nstrings to their raw value equivalent. This conversion is done at\nruntime when the vis is rendered and only updated when the visualization\nis saved. Thus this conversion does not dirty the state of the\nvisualization such as when first opening to edit.\n\nThis _should_ have no affect to the user apart from improved value\nformatting in the color mapping assignment selection UI. In rare cases,\nsome assignments may not be correctly converted exactly to the new raw\nvalue but are still preserved to use as string value matches. The only\nknow case where we are not be able to fully convert the value is when\nusing labels on custom ranges, the label will not show in the color\nmapping assignment UI unless the value is removed as added back.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Marco Liberati <dej611@users.noreply.github.com>\nCo-authored-by: Marco Vettorello <marco.vettorello@elastic.co>","sha":"fa1512572c0467bc3b3c4b637db69b394302cd00"}},"sourceBranch":"main","suggestedTargetBranches":["8.19"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/207957","number":207957,"mergeCommit":{"message":"[ColorMapping] Store assignments as raw/serialized values (#207957)\n\n## Summary\n\nRefactors color mapping logic to store raw values in save objects.\n\nMain changes:\n\n- Instead assignments having a single rule with many values, we now have\nassignments with multiple rules of varying types with a single value.\n- As per the previous change, there is no more explicit `auto` rule,\nthis is now implicit when there are no rules in the assignment.\n- Raw values can now be raw and in cases such as `RangeKey`s and\n`MultiValueKey`s can be instance values. This is not ok for storing in\nredux nor the SO so be have added a `serialize` methods to facilitate\nthis value storage. Code changes attempt to identify which value is used\nbased on variable/param names and type aliases as both are `unknown`.\n- For values that are non-string or non-number types, we no longer allow\ncreating custom matching options.\n- Values are now correctly formatted.\n- Add runtime migration for `xy`, `partition`, `tagcloud` and\n`datatable` viz. Requires `formBased` `datasourceState` to determine\nbest string-to-raw value convertion.\n\nCloses #193080\nFixes #187519\n\n### Checklist\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\n- [x]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas added for features that require explanation or tutorials\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [x] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n### Identify risks\n\n\n\n- [x] Migration from previous stored types.\n\n## Release note\n\nThis PR fixes an issue\n([#193080](#193080)) where\ncustom ranges and multi-field values were not correctly colored based on\nselected color mapping configurations.\n\nThis change includes a runtime migration to convert old mappings as\nstrings to their raw value equivalent. This conversion is done at\nruntime when the vis is rendered and only updated when the visualization\nis saved. Thus this conversion does not dirty the state of the\nvisualization such as when first opening to edit.\n\nThis _should_ have no affect to the user apart from improved value\nformatting in the color mapping assignment selection UI. In rare cases,\nsome assignments may not be correctly converted exactly to the new raw\nvalue but are still preserved to use as string value matches. The only\nknow case where we are not be able to fully convert the value is when\nusing labels on custom ranges, the label will not show in the color\nmapping assignment UI unless the value is removed as added back.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Marco Liberati <dej611@users.noreply.github.com>\nCo-authored-by: Marco Vettorello <marco.vettorello@elastic.co>","sha":"fa1512572c0467bc3b3c4b637db69b394302cd00"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Marco Liberati <dej611@users.noreply.github.com> Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
kibanamachine
removed
the
backport missing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Refactors color mapping logic to store raw values in save objects.
Main changes:
autorule, this is now implicit when there are no rules in the assignment.RangeKeys andMultiValueKeys can be instance values. This is not ok for storing in redux nor the SO so be have added aserializemethods to facilitate this value storage. Code changes attempt to identify which value is used based on variable/param names and type aliases as both areunknown.xy,partition,tagcloudanddatatableviz. RequiresformBaseddatasourceStateto determine best string-to-raw value convertion.Closes #193080
Fixes #187519
Checklist
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesIdentify risks
Release note
This PR fixes an issue (#193080) where custom ranges and multi-field values were not correctly colored based on selected color mapping configurations.
This change includes a runtime migration to convert old mappings as strings to their raw value equivalent. This conversion is done at runtime when the vis is rendered and only updated when the visualization is saved. Thus this conversion does not dirty the state of the visualization such as when first opening to edit.
This should have no affect to the user apart from improved value formatting in the color mapping assignment selection UI. In rare cases, some assignments may not be correctly converted exactly to the new raw value but are still preserved to use as string value matches. The only know case where we are not be able to fully convert the value is when using labels on custom ranges, the label will not show in the color mapping assignment UI unless the value is removed as added back.