[Dashboard] Composable content management transforms#213831
[Dashboard] Composable content management transforms#213831nickpeihl merged 17 commits intoelastic:mainfrom
Conversation
…contract" This reverts commit b3d4e48.
a0092bc to
092c58a
Compare
| if (control.width === 'auto') { | ||
| return { ...control, width: DEFAULT_CONTROL_WIDTH, grow: true }; | ||
| } |
There was a problem hiding this comment.
This is the transform that fixes #211113.
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#8024[✅] x-pack/test/functional/apps/dashboard/group2/config.ts: 100/100 tests passed. |
thomasneirynck
left a comment
There was a problem hiding this comment.
Isolating each step into a function makes sense to me.
Do we know why x-pack/test/functional/apps/dashboard/group2/migration_smoke_tests/controls_migration_smoke_test.ts not capture this? Should that test be expanded to capture this bug in the future?
CI runs functional tests in against a Kibana build, not against a dev server from source. Since #166919, any server validation errors are not surfaced to the user in Kibana builds, but logged as a warning in the server logs. So the CI test renders the page without errors. However, server validation errors are thrown when running in dev mode and typically functional tests are run locally against a dev server. Since validation fails due to an unrecognized key, the server throws an error. And due to #211659, a 404 page is rendered. The smoke test only checks for embeddable errors, of which there are none on a 404 page. 😄 I've added 7f2a22d which might improve this test. |
ThomThomson
left a comment
There was a problem hiding this comment.
This is very well tested, and well organized! Great to see a formalized transforms system in place, and I'm excited to apply it to Embeddables as well.
Tested this locally by importing the controls smoke test, and also looked through the code.
Would it be possible to name the files with the in and out transforms in a way that is more friendly to searching in vscode using command p? Something like control_group_out_transforms.ts.
Left a few questions, but nothing urgent to change. LGTM!
| return defaults(ignoreParentSettings, DEFAULT_IGNORE_PARENT_SETTINGS); | ||
| } | ||
|
|
||
| function transformIgnoreParentSettingsProperties({ |
There was a problem hiding this comment.
Is this just a noop? Why do we need it?
There was a problem hiding this comment.
I'm using it to extract and provide only supported properties from the saved object. It guards against any unsupported properties that may exist in the saved object. I may be overly cautious here. 🤷
Added some documentation in 460bf34.
There was a problem hiding this comment.
That makes sense. We know how possible it is for strange unsupported keys to end up in the saved object as holdovers from older versions or bugs...
| export const transformControlsState: ( | ||
| serializedControlState: string | ||
| ) => ControlGroupAttributes['controls'] = flow( | ||
| JSON.parse, |
There was a problem hiding this comment.
I wonder if there is any way to give flow explicit types - because right now it seems to pass implicit anys which need to be typed in each individual function.
It isn't necessary to fix this now, but IMO this leaves room for errors because the output of one function isn't guaranteed to be the type that the next function takes. I wonder how RXJS' pipe function handles its strict typing.
There was a problem hiding this comment.
I think we'd have to add a bunch of one-off types to provide to flow.
I've seen core using the similar fp-ts library which seems to infer types. But that whole library seems like overkill. I'd rather just write the functions like transformC(transformB(transformA(input))). 😆
| // TODO We may want to remove setting defaults in the future | ||
| export function transformControlsSetDefaults(controls: SerializableRecord[]) { | ||
| return controls.map((control) => | ||
| defaults(control, { grow: DEFAULT_CONTROL_GROW, width: DEFAULT_CONTROL_WIDTH }) |
There was a problem hiding this comment.
I wonder why the usage of lodash defaults here rather than a spread? Is it just for understandability?
There was a problem hiding this comment.
Good old fashioned laziness. But I think it is better to be consistent and spread works just as well without needing to use lodash defaults. Updated in 1f430b0.
Good idea. Changed in 00da442. |
💚 Build Succeeded
Metrics [docs]
History
|
|
Starting backport for target branches: 8.18, 8.x, 9.0 https://github.com/elastic/kibana/actions/runs/14001650501 |
(cherry picked from commit f123b50)
💔 Some backports could not be created
Note: Successful backport PRs will be merged automatically after passing CI. Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
…215581) # Backport This will backport the following commits from `main` to `8.x`: - [[Dashboard] Composable content management transforms (#213831)](#213831) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Nick Peihl","email":"nick.peihl@elastic.co"},"sourceCommit":{"committedDate":"2025-03-21T22:04:39Z","message":"[Dashboard] Composable content management transforms (#213831)","sha":"f123b5096a92f980a4ea7d0b5410388c21c469e1","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Presentation","v9.0.0","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[Dashboard] Composable content management transforms","number":213831,"url":"https://github.com/elastic/kibana/pull/213831","mergeCommit":{"message":"[Dashboard] Composable content management transforms (#213831)","sha":"f123b5096a92f980a4ea7d0b5410388c21c469e1"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/213831","number":213831,"mergeCommit":{"message":"[Dashboard] Composable content management transforms (#213831)","sha":"f123b5096a92f980a4ea7d0b5410388c21c469e1"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Nick Peihl <nick.peihl@elastic.co>


Fixes #211113
Summary
Fixes a bug where a control having a width of "auto" causes the dashboard to be invalid.
This bug only surfaced to users as a warning of an Invalid dashboard in Kibana server logs. In development environments (such as
yarn startor running functional tests locally) the bug would have thrown an error. CI would not catch the bug due to running functional tests using a production build of Kibana.As part of this fix, I've updated the Dashboard content management transforms to use smaller, composable functions. This makes it easier to read, add, or update transforms for dashboards. Additionally, this adds a transform function that fixes the bug in #211113 at runtime rather than via a saved object migration which are no longer supported.
Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:*label is applied per the guidelinesIdentify risks
Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.