[Security Solution] Searchbar edit filter does not populate with prebuilt rules #209518
Assignees
Labels
8.18 candidate
bug
Fixes for quality problems that affect the customer experience
Feature:Prebuilt Detection Rules
Security Solution Prebuilt Detection Rules area
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
v8.18.0
Comments
dplumlee
added
bug
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
1 task
banderror
added
impact:medium
|
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
72 tasks
|
@dplumlee @maximpn Thanks for catching this one. It's pretty bad and we should fix it when we release Milestone 3 in ESS in |
dplumlee
added a commit
that referenced
this issue
Feb 25, 2025
…210191) **Fixes: #206527 **Partially addresses: #209518 ## Summary Adds a normalization to the `filters` field in the rule diffing calculation that omits all filter fields other than the `query` field and the `negate` and `disabled` fields within the `meta` object. This makes our diffing logic much more robust and resilient as we only compare data in the rule fields that have an impact on the query itself and not the fields that relate to UI implementation (`alias`, `key`, etc). ### To test - Open a prebuilt rule with `filters` in the non-customized rule parameters (e.g. `PowerShell Script with Discovery Capabilities`) - Edit the rule and save without editing - The rule should remain unmodified even though more fields have been added to the rule's `filters` field Unless the user adds or deletes a filter on the rule, the rule should only be marked as customized under 3 circumstances: - The user negates the filter (adds NOT to the beginning of the filter) - The user disables the filter - The user changes the filter query All other scenarios (such as adding a custom name for the filter) should not change the rule's customized status ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Feb 25, 2025
…lastic#210191) **Fixes: elastic#206527 **Partially addresses: elastic#209518 ## Summary Adds a normalization to the `filters` field in the rule diffing calculation that omits all filter fields other than the `query` field and the `negate` and `disabled` fields within the `meta` object. This makes our diffing logic much more robust and resilient as we only compare data in the rule fields that have an impact on the query itself and not the fields that relate to UI implementation (`alias`, `key`, etc). ### To test - Open a prebuilt rule with `filters` in the non-customized rule parameters (e.g. `PowerShell Script with Discovery Capabilities`) - Edit the rule and save without editing - The rule should remain unmodified even though more fields have been added to the rule's `filters` field Unless the user adds or deletes a filter on the rule, the rule should only be marked as customized under 3 circumstances: - The user negates the filter (adds NOT to the beginning of the filter) - The user disables the filter - The user changes the filter query All other scenarios (such as adding a custom name for the filter) should not change the rule's customized status ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 (cherry picked from commit 3f3c8c8)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Feb 25, 2025
…lastic#210191) **Fixes: elastic#206527 **Partially addresses: elastic#209518 ## Summary Adds a normalization to the `filters` field in the rule diffing calculation that omits all filter fields other than the `query` field and the `negate` and `disabled` fields within the `meta` object. This makes our diffing logic much more robust and resilient as we only compare data in the rule fields that have an impact on the query itself and not the fields that relate to UI implementation (`alias`, `key`, etc). ### To test - Open a prebuilt rule with `filters` in the non-customized rule parameters (e.g. `PowerShell Script with Discovery Capabilities`) - Edit the rule and save without editing - The rule should remain unmodified even though more fields have been added to the rule's `filters` field Unless the user adds or deletes a filter on the rule, the rule should only be marked as customized under 3 circumstances: - The user negates the filter (adds NOT to the beginning of the filter) - The user disables the filter - The user changes the filter query All other scenarios (such as adding a custom name for the filter) should not change the rule's customized status ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 (cherry picked from commit 3f3c8c8)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this issue
Feb 25, 2025
…lastic#210191) **Fixes: elastic#206527 **Partially addresses: elastic#209518 ## Summary Adds a normalization to the `filters` field in the rule diffing calculation that omits all filter fields other than the `query` field and the `negate` and `disabled` fields within the `meta` object. This makes our diffing logic much more robust and resilient as we only compare data in the rule fields that have an impact on the query itself and not the fields that relate to UI implementation (`alias`, `key`, etc). ### To test - Open a prebuilt rule with `filters` in the non-customized rule parameters (e.g. `PowerShell Script with Discovery Capabilities`) - Edit the rule and save without editing - The rule should remain unmodified even though more fields have been added to the rule's `filters` field Unless the user adds or deletes a filter on the rule, the rule should only be marked as customized under 3 circumstances: - The user negates the filter (adds NOT to the beginning of the filter) - The user disables the filter - The user changes the filter query All other scenarios (such as adding a custom name for the filter) should not change the rule's customized status ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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 (cherry picked from commit 3f3c8c8)
patrykkopycinski
pushed a commit
to patrykkopycinski/kibana
that referenced
this issue
Feb 25, 2025
…lastic#210191) **Fixes: elastic#206527 **Partially addresses: elastic#209518 ## Summary Adds a normalization to the `filters` field in the rule diffing calculation that omits all filter fields other than the `query` field and the `negate` and `disabled` fields within the `meta` object. This makes our diffing logic much more robust and resilient as we only compare data in the rule fields that have an impact on the query itself and not the fields that relate to UI implementation (`alias`, `key`, etc). ### To test - Open a prebuilt rule with `filters` in the non-customized rule parameters (e.g. `PowerShell Script with Discovery Capabilities`) - Edit the rule and save without editing - The rule should remain unmodified even though more fields have been added to the rule's `filters` field Unless the user adds or deletes a filter on the rule, the rule should only be marked as customized under 3 circumstances: - The user negates the filter (adds NOT to the beginning of the filter) - The user disables the filter - The user changes the filter query All other scenarios (such as adding a custom name for the filter) should not change the rule's customized status ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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
JoseLuisGJ
pushed a commit
to JoseLuisGJ/kibana
that referenced
this issue
Feb 27, 2025
…lastic#210191) **Fixes: elastic#206527 **Partially addresses: elastic#209518 ## Summary Adds a normalization to the `filters` field in the rule diffing calculation that omits all filter fields other than the `query` field and the `negate` and `disabled` fields within the `meta` object. This makes our diffing logic much more robust and resilient as we only compare data in the rule fields that have an impact on the query itself and not the fields that relate to UI implementation (`alias`, `key`, etc). ### To test - Open a prebuilt rule with `filters` in the non-customized rule parameters (e.g. `PowerShell Script with Discovery Capabilities`) - Edit the rule and save without editing - The rule should remain unmodified even though more fields have been added to the rule's `filters` field Unless the user adds or deletes a filter on the rule, the rule should only be marked as customized under 3 circumstances: - The user negates the filter (adds NOT to the beginning of the filter) - The user disables the filter - The user changes the filter query All other scenarios (such as adding a custom name for the filter) should not change the rule's customized status ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Epic: #174168
Summary
Related to:
filtersfield before rule diff comparison #206344When filters are edited from non-customized prebuilt rules, the filter modal does not populate correctly and the user is forced to select a data view. This is fixed when a filter or index pattern field is changed and the rule is saved but all other filters in the
filtersfield have an addedmeta .indexfield added to them which is causing prebuilt rule upgrade previews to have unexpected results (seen here).To reproduce
Threat Intel Hash Indicator Match)Expected Result:
The data view selector is not shown and the filter edit component correctly populates with the filter details
Actual Result:
The data view selector is shown and no fields are populated in the component
Note:
If a rule filter is deleted/added, upon saving the rule in the UI, the
filtersfield will have ameta.indexfield added to each filter which solves this issue (code introduced here). This fix was only implemented before prebuilt rules were allowed to be edited and out of the box they don't contain thismeta.indexfield theSearchbarfilters component requires to function properly. Thesemeta.indexfields show up as customizations in theupgrade/_reviewworkflow as they are not shipped in the TRADE prebuilt rule packages and could be confusing to users.The text was updated successfully, but these errors were encountered: