[Lens][Embeddable] Apply the correct references for filters #204047
Merged
Conversation
This file contains 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
dej611
added
Team:Visualizations
|
/ci |
|
Pinging @elastic/kibana-visualizations (Team:Visualizations) |
markov00
approved these changes
Dec 19, 2024
|
I've got a PR for that |
|
Starting backport for target branches: 8.x |
💚 Build Succeeded
Metrics [docs]Async chunks
History
|
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Dec 19, 2024
…204047) ## Summary Fixes elastic#180726 Fix the filter references when inline editing with the correct ones. I've tried to reduce the fix to a minimal `extract` wrapper, but unfortunately that is not possible due to some shared logic who rely on the passed filters references and need to be injected. So, why not injecting them and instead rely on the search context api? Right now there's no difference, but formally the `api.filters$` is the right place to get the latest version, and if in the future the `Edit filters` flows would change, this api should be the go-to place to have the right value. Why not adding a FTR? There's a bigger problem with the panel filters action who has a dynamic `data-test-subj` value which is impossible to get right now. I would rather prefer to fix that first and then add some tests in general for multiple scenarios in Lens. ## Testing it locally * Create a viz with a filter in the editor, save and return to dashboard * Check the filters are shown correctly in the dashboard panel * Edit inline and change the chart type. Apply changes * Check the filters are shown correctly * Now "edit" in the editor without changing anything * Check the filter can be edited correctly (no empty popover) ✅ or 💥 * Save and return to dashboard * Check the filters are shown correctly ✅ or 💥 (cherry picked from commit c521c1c)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
Dec 19, 2024
…04047) (#205000) # Backport This will backport the following commits from `main` to `8.x`: - [[Lens][Embeddable] Apply the correct references for filters (#204047)](#204047) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Marco Liberati","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-12-19T19:34:49Z","message":"[Lens][Embeddable] Apply the correct references for filters (#204047)\n\n## Summary\r\n\r\nFixes #180726\r\n\r\nFix the filter references when inline editing with the correct ones.\r\n\r\nI've tried to reduce the fix to a minimal `extract` wrapper, but\r\nunfortunately that is not possible due to some shared logic who rely on\r\nthe passed filters references and need to be injected.\r\nSo, why not injecting them and instead rely on the search context api?\r\nRight now there's no difference, but formally the `api.filters# Backport This will backport the following commits from `main` to `8.x`: - [[Lens][Embeddable] Apply the correct references for filters (#204047)](#204047) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT is the\r\nright place to get the latest version, and if in the future the `Edit\r\nfilters` flows would change, this api should be the go-to place to have\r\nthe right value.\r\n\r\nWhy not adding a FTR?\r\nThere's a bigger problem with the panel filters action who has a dynamic\r\n`data-test-subj` value which is impossible to get right now. I would\r\nrather prefer to fix that first and then add some tests in general for\r\nmultiple scenarios in Lens.\r\n\r\n## Testing it locally\r\n\r\n* Create a viz with a filter in the editor, save and return to dashboard\r\n* Check the filters are shown correctly in the dashboard panel\r\n* Edit inline and change the chart type. Apply changes\r\n* Check the filters are shown correctly\r\n* Now \"edit\" in the editor without changing anything\r\n* Check the filter can be edited correctly (no empty popover) ✅ or 💥 \r\n* Save and return to dashboard\r\n* Check the filters are shown correctly ✅ or 💥","sha":"c521c1c139a4a661c76be83497bc18affdda0857","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Visualizations","release_note:skip","Feature:Lens","v9.0.0","backport:prev-minor"],"title":"[Lens][Embeddable] Apply the correct references for filters","number":204047,"url":"https://github.com/elastic/kibana/pull/204047","mergeCommit":{"message":"[Lens][Embeddable] Apply the correct references for filters (#204047)\n\n## Summary\r\n\r\nFixes #180726\r\n\r\nFix the filter references when inline editing with the correct ones.\r\n\r\nI've tried to reduce the fix to a minimal `extract` wrapper, but\r\nunfortunately that is not possible due to some shared logic who rely on\r\nthe passed filters references and need to be injected.\r\nSo, why not injecting them and instead rely on the search context api?\r\nRight now there's no difference, but formally the `api.filters# Backport This will backport the following commits from `main` to `8.x`: - [[Lens][Embeddable] Apply the correct references for filters (#204047)](#204047) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT is the\r\nright place to get the latest version, and if in the future the `Edit\r\nfilters` flows would change, this api should be the go-to place to have\r\nthe right value.\r\n\r\nWhy not adding a FTR?\r\nThere's a bigger problem with the panel filters action who has a dynamic\r\n`data-test-subj` value which is impossible to get right now. I would\r\nrather prefer to fix that first and then add some tests in general for\r\nmultiple scenarios in Lens.\r\n\r\n## Testing it locally\r\n\r\n* Create a viz with a filter in the editor, save and return to dashboard\r\n* Check the filters are shown correctly in the dashboard panel\r\n* Edit inline and change the chart type. Apply changes\r\n* Check the filters are shown correctly\r\n* Now \"edit\" in the editor without changing anything\r\n* Check the filter can be edited correctly (no empty popover) ✅ or 💥 \r\n* Save and return to dashboard\r\n* Check the filters are shown correctly ✅ or 💥","sha":"c521c1c139a4a661c76be83497bc18affdda0857"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/204047","number":204047,"mergeCommit":{"message":"[Lens][Embeddable] Apply the correct references for filters (#204047)\n\n## Summary\r\n\r\nFixes #180726\r\n\r\nFix the filter references when inline editing with the correct ones.\r\n\r\nI've tried to reduce the fix to a minimal `extract` wrapper, but\r\nunfortunately that is not possible due to some shared logic who rely on\r\nthe passed filters references and need to be injected.\r\nSo, why not injecting them and instead rely on the search context api?\r\nRight now there's no difference, but formally the `api.filters# Backport This will backport the following commits from `main` to `8.x`: - [[Lens][Embeddable] Apply the correct references for filters (#204047)](#204047) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT is the\r\nright place to get the latest version, and if in the future the `Edit\r\nfilters` flows would change, this api should be the go-to place to have\r\nthe right value.\r\n\r\nWhy not adding a FTR?\r\nThere's a bigger problem with the panel filters action who has a dynamic\r\n`data-test-subj` value which is impossible to get right now. I would\r\nrather prefer to fix that first and then add some tests in general for\r\nmultiple scenarios in Lens.\r\n\r\n## Testing it locally\r\n\r\n* Create a viz with a filter in the editor, save and return to dashboard\r\n* Check the filters are shown correctly in the dashboard panel\r\n* Edit inline and change the chart type. Apply changes\r\n* Check the filters are shown correctly\r\n* Now \"edit\" in the editor without changing anything\r\n* Check the filter can be edited correctly (no empty popover) ✅ or 💥 \r\n* Save and return to dashboard\r\n* Check the filters are shown correctly ✅ or 💥","sha":"c521c1c139a4a661c76be83497bc18affdda0857"}}]}] BACKPORT--> Co-authored-by: Marco Liberati <[email protected]>
stratoula
pushed a commit
to stratoula/kibana
that referenced
this pull request
Jan 2, 2025
…204047) ## Summary Fixes elastic#180726 Fix the filter references when inline editing with the correct ones. I've tried to reduce the fix to a minimal `extract` wrapper, but unfortunately that is not possible due to some shared logic who rely on the passed filters references and need to be injected. So, why not injecting them and instead rely on the search context api? Right now there's no difference, but formally the `api.filters$` is the right place to get the latest version, and if in the future the `Edit filters` flows would change, this api should be the go-to place to have the right value. Why not adding a FTR? There's a bigger problem with the panel filters action who has a dynamic `data-test-subj` value which is impossible to get right now. I would rather prefer to fix that first and then add some tests in general for multiple scenarios in Lens. ## Testing it locally * Create a viz with a filter in the editor, save and return to dashboard * Check the filters are shown correctly in the dashboard panel * Edit inline and change the chart type. Apply changes * Check the filters are shown correctly * Now "edit" in the editor without changing anything * Check the filter can be edited correctly (no empty popover) ✅ or 💥 * Save and return to dashboard * Check the filters are shown correctly ✅ or 💥
benakansara
pushed a commit
to benakansara/kibana
that referenced
this pull request
Jan 2, 2025
…204047) ## Summary Fixes elastic#180726 Fix the filter references when inline editing with the correct ones. I've tried to reduce the fix to a minimal `extract` wrapper, but unfortunately that is not possible due to some shared logic who rely on the passed filters references and need to be injected. So, why not injecting them and instead rely on the search context api? Right now there's no difference, but formally the `api.filters$` is the right place to get the latest version, and if in the future the `Edit filters` flows would change, this api should be the go-to place to have the right value. Why not adding a FTR? There's a bigger problem with the panel filters action who has a dynamic `data-test-subj` value which is impossible to get right now. I would rather prefer to fix that first and then add some tests in general for multiple scenarios in Lens. ## Testing it locally * Create a viz with a filter in the editor, save and return to dashboard * Check the filters are shown correctly in the dashboard panel * Edit inline and change the chart type. Apply changes * Check the filters are shown correctly * Now "edit" in the editor without changing anything * Check the filter can be edited correctly (no empty popover) ✅ or 💥 * Save and return to dashboard * Check the filters are shown correctly ✅ or 💥
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Fixes #180726
Fix the filter references when inline editing with the correct ones.
I've tried to reduce the fix to a minimal
extractwrapper, but unfortunately that is not possible due to some shared logic who rely on the passed filters references and need to be injected.So, why not injecting them and instead rely on the search context api?
Right now there's no difference, but formally the
api.filters$is the right place to get the latest version, and if in the future theEdit filtersflows would change, this api should be the go-to place to have the right value.Why not adding a FTR?
There's a bigger problem with the panel filters action who has a dynamic
data-test-subjvalue which is impossible to get right now. I would rather prefer to fix that first and then add some tests in general for multiple scenarios in Lens.Testing it locally