[Security Solution] Searchbar edit filter does not populate with prebuilt rules

[dplumlee]

Epic: #174168

Summary

Related to:

• [Security Solution] "Data view" selector is shown in "Edit filter" view on the Rule Editing page #174026
• [Security Solution] "Data view" selector is shown in "Edit filter" view on the Rule Editing page (#174026) #174922
• [Security Solution] Normalizes filters field before rule diff comparison  #206344
• [Security Solution] Prebuilt Rule with query filters incorrectly marked as customized after saving without changes #206527

When 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 filters field have an added meta .index field added to them which is causing prebuilt rule upgrade previews to have unexpected results (seen here).

To reproduce

• Install prebuilt rules
• Open a rule that contains filters (for example Threat Intel Hash Indicator Match)
• Attempt to edit a filter

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 filters field will have a meta.index field 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 this meta.index field the Searchbar filters component requires to function properly. These meta.index fields show up as customizations in the upgrade/_review workflow as they are not shipped in the TRADE prebuilt rule packages and could be confusing to users.

---

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[banderror]

@dplumlee @maximpn Thanks for catching this one. It's pretty bad and we should fix it when we release Milestone 3 in ESS in v8.18.0, but I'm not sure if we should consider this a blocker for the first release in Serverless. I'd say probably not. Let's try to fix it by Feb 13th, but if we can't that's ok.