[One Discover] Prevent search highlighting markup in logs overview field action filters#227652
Merged
rStelmach merged 2 commits intoelastic:mainfrom Jul 24, 2025
Conversation
… value will be used when field actions are used in the logs overview tab
rStelmach
added
Feature:Discover
Contributor
|
Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs) |
rStelmach
changed the title
Contributor
💚 Build Succeeded
Metrics [docs]Async chunks
|
tonyghiani
approved these changes
Jul 24, 2025
Contributor
tonyghiani
left a comment
tonyghiani
left a comment
There was a problem hiding this comment.
LGTM, thanks for the fix!
Contributor
|
Starting backport for target branches: 8.19, 9.1 |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jul 24, 2025
…eld action filters (elastic#227652) closes : elastic#226375 ## Summary 📚 Fixes an issue where HTML search highlighting markup (`<mark>` tags) was incorrectly carried over into filter values when using field actions "Filter for value" in the logs overview tab. ### Problem 🐛 When searching in Discover and using field actions in the logs overview tab's content breakdown section, the generated filters would contain HTML markup instead of clean field values. The logs overview components were using the formatted/highlighted field values (which contain ` <mark> ` tags for visual highlighting) directly in field actions, instead of accessing the original, clean field values from the raw document. ### Solution Instead of trying to strip HTML markup (which could accidentally remove legitimate HTML content from log messages), this fix implements a cleaner approach which is passing raw document data. ## Demo 🎥 https://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58 ## How to test 🔬 - Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js simple_logs) - Write a search query that matches part or all of the message - Open the doc flyout and use an action for the message field ## Open discussion 🗣️ This solution is also handling an edge case when a message can contain `<mark>` html element and that's why we are passing raw doc message. If that is too much we can just use regex to filter out `<mark>` html markups caused by our highlighting. LMK (cherry picked from commit d94e367)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jul 24, 2025
…eld action filters (elastic#227652) closes : elastic#226375 ## Summary 📚 Fixes an issue where HTML search highlighting markup (`<mark>` tags) was incorrectly carried over into filter values when using field actions "Filter for value" in the logs overview tab. ### Problem 🐛 When searching in Discover and using field actions in the logs overview tab's content breakdown section, the generated filters would contain HTML markup instead of clean field values. The logs overview components were using the formatted/highlighted field values (which contain ` <mark> ` tags for visual highlighting) directly in field actions, instead of accessing the original, clean field values from the raw document. ### Solution Instead of trying to strip HTML markup (which could accidentally remove legitimate HTML content from log messages), this fix implements a cleaner approach which is passing raw document data. ## Demo 🎥 https://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58 ## How to test 🔬 - Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js simple_logs) - Write a search query that matches part or all of the message - Open the doc flyout and use an action for the message field ## Open discussion 🗣️ This solution is also handling an edge case when a message can contain `<mark>` html element and that's why we are passing raw doc message. If that is too much we can just use regex to filter out `<mark>` html markups caused by our highlighting. LMK (cherry picked from commit d94e367)
Contributor
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kertal
pushed a commit
to kertal/kibana
that referenced
this pull request
Jul 25, 2025
…eld action filters (elastic#227652) closes : elastic#226375 ## Summary 📚 Fixes an issue where HTML search highlighting markup (`<mark>` tags) was incorrectly carried over into filter values when using field actions "Filter for value" in the logs overview tab. ### Problem 🐛 When searching in Discover and using field actions in the logs overview tab's content breakdown section, the generated filters would contain HTML markup instead of clean field values. The logs overview components were using the formatted/highlighted field values (which contain ` <mark> ` tags for visual highlighting) directly in field actions, instead of accessing the original, clean field values from the raw document. ### Solution Instead of trying to strip HTML markup (which could accidentally remove legitimate HTML content from log messages), this fix implements a cleaner approach which is passing raw document data. ## Demo 🎥 https://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58 ## How to test 🔬 - Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js simple_logs) - Write a search query that matches part or all of the message - Open the doc flyout and use an action for the message field ## Open discussion 🗣️ This solution is also handling an edge case when a message can contain `<mark>` html element and that's why we are passing raw doc message. If that is too much we can just use regex to filter out `<mark>` html markups caused by our highlighting. LMK
kibanamachine
added
the
backport missing
Contributor
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
rStelmach
added a commit
that referenced
this pull request
Jul 25, 2025
…view field action filters (#227652) (#229288) # Backport This will backport the following commits from `main` to `8.19`: - [[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)](#227652) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Robert Stelmach","email":"60304951+rStelmach@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-07-24T10:35:29Z","message":"[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)\n\ncloses : #226375\n## Summary 📚 \nFixes an issue where HTML search highlighting markup (`<mark>` tags) was\nincorrectly carried over into filter values when using field actions\n\"Filter for value\" in the logs overview tab.\n\n### Problem 🐛 \nWhen searching in Discover and using field actions in the logs overview\ntab's content breakdown section, the generated filters would contain\nHTML markup instead of clean field values.\nThe logs overview components were using the formatted/highlighted field\nvalues (which contain ` <mark> ` tags for visual highlighting) directly\nin field actions, instead of accessing the original, clean field values\nfrom the raw document.\n\n### Solution\nInstead of trying to strip HTML markup (which could accidentally remove\nlegitimate HTML content from log messages), this fix implements a\ncleaner approach which is passing raw document data.\n\n## Demo 🎥 \n\n\nhttps://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58\n\n## How to test 🔬 \n\n- Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js\nsimple_logs)\n- Write a search query that matches part or all of the message\n- Open the doc flyout and use an action for the message field\n\n## Open discussion 🗣️ \nThis solution is also handling an edge case when a message can contain\n`<mark>` html element and that's why we are passing raw doc message.\nIf that is too much we can just use regex to filter out `<mark>` html\nmarkups caused by our highlighting. LMK","sha":"d94e367e4fab13adb532247ee8949394d4a95e0b","branchLabelMapping":{"^v9.2.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Discover","release_note:fix","Team:obs-ux-logs","Project:OneDiscover","backport:version","v9.1.0","v8.19.0","v9.2.0"],"title":"[One Discover] Prevent search highlighting markup in logs overview field action filters","number":227652,"url":"https://github.com/elastic/kibana/pull/227652","mergeCommit":{"message":"[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)\n\ncloses : #226375\n## Summary 📚 \nFixes an issue where HTML search highlighting markup (`<mark>` tags) was\nincorrectly carried over into filter values when using field actions\n\"Filter for value\" in the logs overview tab.\n\n### Problem 🐛 \nWhen searching in Discover and using field actions in the logs overview\ntab's content breakdown section, the generated filters would contain\nHTML markup instead of clean field values.\nThe logs overview components were using the formatted/highlighted field\nvalues (which contain ` <mark> ` tags for visual highlighting) directly\nin field actions, instead of accessing the original, clean field values\nfrom the raw document.\n\n### Solution\nInstead of trying to strip HTML markup (which could accidentally remove\nlegitimate HTML content from log messages), this fix implements a\ncleaner approach which is passing raw document data.\n\n## Demo 🎥 \n\n\nhttps://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58\n\n## How to test 🔬 \n\n- Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js\nsimple_logs)\n- Write a search query that matches part or all of the message\n- Open the doc flyout and use an action for the message field\n\n## Open discussion 🗣️ \nThis solution is also handling an edge case when a message can contain\n`<mark>` html element and that's why we are passing raw doc message.\nIf that is too much we can just use regex to filter out `<mark>` html\nmarkups caused by our highlighting. LMK","sha":"d94e367e4fab13adb532247ee8949394d4a95e0b"}},"sourceBranch":"main","suggestedTargetBranches":["9.1","8.19"],"targetPullRequestStates":[{"branch":"9.1","label":"v9.1.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.2.0","branchLabelMappingKey":"^v9.2.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/227652","number":227652,"mergeCommit":{"message":"[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)\n\ncloses : #226375\n## Summary 📚 \nFixes an issue where HTML search highlighting markup (`<mark>` tags) was\nincorrectly carried over into filter values when using field actions\n\"Filter for value\" in the logs overview tab.\n\n### Problem 🐛 \nWhen searching in Discover and using field actions in the logs overview\ntab's content breakdown section, the generated filters would contain\nHTML markup instead of clean field values.\nThe logs overview components were using the formatted/highlighted field\nvalues (which contain ` <mark> ` tags for visual highlighting) directly\nin field actions, instead of accessing the original, clean field values\nfrom the raw document.\n\n### Solution\nInstead of trying to strip HTML markup (which could accidentally remove\nlegitimate HTML content from log messages), this fix implements a\ncleaner approach which is passing raw document data.\n\n## Demo 🎥 \n\n\nhttps://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58\n\n## How to test 🔬 \n\n- Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js\nsimple_logs)\n- Write a search query that matches part or all of the message\n- Open the doc flyout and use an action for the message field\n\n## Open discussion 🗣️ \nThis solution is also handling an edge case when a message can contain\n`<mark>` html element and that's why we are passing raw doc message.\nIf that is too much we can just use regex to filter out `<mark>` html\nmarkups caused by our highlighting. LMK","sha":"d94e367e4fab13adb532247ee8949394d4a95e0b"}}]}] BACKPORT--> --------- Co-authored-by: Robert Stelmach <60304951+rStelmach@users.noreply.github.com> Co-authored-by: Robert Stelmach <robert.stelmach@elastic.co>
rStelmach
added a commit
that referenced
this pull request
Jul 25, 2025
…iew field action filters (#227652) (#229289) # Backport This will backport the following commits from `main` to `9.1`: - [[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)](#227652) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Robert Stelmach","email":"60304951+rStelmach@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-07-24T10:35:29Z","message":"[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)\n\ncloses : #226375\n## Summary 📚 \nFixes an issue where HTML search highlighting markup (`<mark>` tags) was\nincorrectly carried over into filter values when using field actions\n\"Filter for value\" in the logs overview tab.\n\n### Problem 🐛 \nWhen searching in Discover and using field actions in the logs overview\ntab's content breakdown section, the generated filters would contain\nHTML markup instead of clean field values.\nThe logs overview components were using the formatted/highlighted field\nvalues (which contain ` <mark> ` tags for visual highlighting) directly\nin field actions, instead of accessing the original, clean field values\nfrom the raw document.\n\n### Solution\nInstead of trying to strip HTML markup (which could accidentally remove\nlegitimate HTML content from log messages), this fix implements a\ncleaner approach which is passing raw document data.\n\n## Demo 🎥 \n\n\nhttps://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58\n\n## How to test 🔬 \n\n- Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js\nsimple_logs)\n- Write a search query that matches part or all of the message\n- Open the doc flyout and use an action for the message field\n\n## Open discussion 🗣️ \nThis solution is also handling an edge case when a message can contain\n`<mark>` html element and that's why we are passing raw doc message.\nIf that is too much we can just use regex to filter out `<mark>` html\nmarkups caused by our highlighting. LMK","sha":"d94e367e4fab13adb532247ee8949394d4a95e0b","branchLabelMapping":{"^v9.2.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Discover","release_note:fix","Team:obs-ux-logs","Project:OneDiscover","backport:version","v9.1.0","v8.19.0","v9.2.0"],"title":"[One Discover] Prevent search highlighting markup in logs overview field action filters","number":227652,"url":"https://github.com/elastic/kibana/pull/227652","mergeCommit":{"message":"[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)\n\ncloses : #226375\n## Summary 📚 \nFixes an issue where HTML search highlighting markup (`<mark>` tags) was\nincorrectly carried over into filter values when using field actions\n\"Filter for value\" in the logs overview tab.\n\n### Problem 🐛 \nWhen searching in Discover and using field actions in the logs overview\ntab's content breakdown section, the generated filters would contain\nHTML markup instead of clean field values.\nThe logs overview components were using the formatted/highlighted field\nvalues (which contain ` <mark> ` tags for visual highlighting) directly\nin field actions, instead of accessing the original, clean field values\nfrom the raw document.\n\n### Solution\nInstead of trying to strip HTML markup (which could accidentally remove\nlegitimate HTML content from log messages), this fix implements a\ncleaner approach which is passing raw document data.\n\n## Demo 🎥 \n\n\nhttps://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58\n\n## How to test 🔬 \n\n- Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js\nsimple_logs)\n- Write a search query that matches part or all of the message\n- Open the doc flyout and use an action for the message field\n\n## Open discussion 🗣️ \nThis solution is also handling an edge case when a message can contain\n`<mark>` html element and that's why we are passing raw doc message.\nIf that is too much we can just use regex to filter out `<mark>` html\nmarkups caused by our highlighting. LMK","sha":"d94e367e4fab13adb532247ee8949394d4a95e0b"}},"sourceBranch":"main","suggestedTargetBranches":["9.1","8.19"],"targetPullRequestStates":[{"branch":"9.1","label":"v9.1.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.2.0","branchLabelMappingKey":"^v9.2.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/227652","number":227652,"mergeCommit":{"message":"[One Discover] Prevent search highlighting markup in logs overview field action filters (#227652)\n\ncloses : #226375\n## Summary 📚 \nFixes an issue where HTML search highlighting markup (`<mark>` tags) was\nincorrectly carried over into filter values when using field actions\n\"Filter for value\" in the logs overview tab.\n\n### Problem 🐛 \nWhen searching in Discover and using field actions in the logs overview\ntab's content breakdown section, the generated filters would contain\nHTML markup instead of clean field values.\nThe logs overview components were using the formatted/highlighted field\nvalues (which contain ` <mark> ` tags for visual highlighting) directly\nin field actions, instead of accessing the original, clean field values\nfrom the raw document.\n\n### Solution\nInstead of trying to strip HTML markup (which could accidentally remove\nlegitimate HTML content from log messages), this fix implements a\ncleaner approach which is passing raw document data.\n\n## Demo 🎥 \n\n\nhttps://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58\n\n## How to test 🔬 \n\n- Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js\nsimple_logs)\n- Write a search query that matches part or all of the message\n- Open the doc flyout and use an action for the message field\n\n## Open discussion 🗣️ \nThis solution is also handling an edge case when a message can contain\n`<mark>` html element and that's why we are passing raw doc message.\nIf that is too much we can just use regex to filter out `<mark>` html\nmarkups caused by our highlighting. LMK","sha":"d94e367e4fab13adb532247ee8949394d4a95e0b"}}]}] BACKPORT--> --------- Co-authored-by: Robert Stelmach <60304951+rStelmach@users.noreply.github.com> Co-authored-by: Robert Stelmach <robert.stelmach@elastic.co>
kibanamachine
removed
the
backport missing
eokoneyo
pushed a commit
to eokoneyo/kibana
that referenced
this pull request
Jul 31, 2025
…eld action filters (elastic#227652) closes : elastic#226375 ## Summary 📚 Fixes an issue where HTML search highlighting markup (`<mark>` tags) was incorrectly carried over into filter values when using field actions "Filter for value" in the logs overview tab. ### Problem 🐛 When searching in Discover and using field actions in the logs overview tab's content breakdown section, the generated filters would contain HTML markup instead of clean field values. The logs overview components were using the formatted/highlighted field values (which contain ` <mark> ` tags for visual highlighting) directly in field actions, instead of accessing the original, clean field values from the raw document. ### Solution Instead of trying to strip HTML markup (which could accidentally remove legitimate HTML content from log messages), this fix implements a cleaner approach which is passing raw document data. ## Demo 🎥 https://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58 ## How to test 🔬 - Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js simple_logs) - Write a search query that matches part or all of the message - Open the doc flyout and use an action for the message field ## Open discussion 🗣️ This solution is also handling an edge case when a message can contain `<mark>` html element and that's why we are passing raw doc message. If that is too much we can just use regex to filter out `<mark>` html markups caused by our highlighting. LMK
rStelmach
deleted the
226375-highlights-are-carried-over-in-field-actions-in-the-logs-overview-tab
branch
delanni
pushed a commit
to delanni/kibana
that referenced
this pull request
Aug 5, 2025
…eld action filters (elastic#227652) closes : elastic#226375 ## Summary 📚 Fixes an issue where HTML search highlighting markup (`<mark>` tags) was incorrectly carried over into filter values when using field actions "Filter for value" in the logs overview tab. ### Problem 🐛 When searching in Discover and using field actions in the logs overview tab's content breakdown section, the generated filters would contain HTML markup instead of clean field values. The logs overview components were using the formatted/highlighted field values (which contain ` <mark> ` tags for visual highlighting) directly in field actions, instead of accessing the original, clean field values from the raw document. ### Solution Instead of trying to strip HTML markup (which could accidentally remove legitimate HTML content from log messages), this fix implements a cleaner approach which is passing raw document data. ## Demo 🎥 https://github.com/user-attachments/assets/286db889-e54b-4026-b5bc-0e3ca9e1ea58 ## How to test 🔬 - Ingest log data (e.g by using Synthtrace node scripts/synthtrace.js simple_logs) - Write a search query that matches part or all of the message - Open the doc flyout and use an action for the message field ## Open discussion 🗣️ This solution is also handling an edge case when a message can contain `<mark>` html element and that's why we are passing raw doc message. If that is too much we can just use regex to filter out `<mark>` html markups caused by our highlighting. LMK
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
5 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.
closes : #226375
Summary 📚
Fixes an issue where HTML search highlighting markup (
<mark>tags) was incorrectly carried over into filter values when using field actions "Filter for value" in the logs overview tab.Problem 🐛
When searching in Discover and using field actions in the logs overview tab's content breakdown section, the generated filters would contain HTML markup instead of clean field values.
The logs overview components were using the formatted/highlighted field values (which contain
<mark>tags for visual highlighting) directly in field actions, instead of accessing the original, clean field values from the raw document.Solution
Instead of trying to strip HTML markup (which could accidentally remove legitimate HTML content from log messages), this fix implements a cleaner approach which is passing raw document data.
Demo 🎥
highlight.test.mov
How to test 🔬
Open discussion 🗣️
This solution is also handling an edge case when a message can contain
<mark>html element and that's why we are passing raw doc message.If that is too much we can just use regex to filter out
<mark>html markups caused by our highlighting. LMK