[Security Solution][Detection Engine] hides 'run query' label on ES|QL rule creation

[vitaliidm]

Summary

• hides Run query ⌘ + Enter label on ES|QL text editor when create/edit rule
• On unified search side, passes property hideTextBasedRunQueryLabel to underlying TextBasedLangEditor component

Before

After

[elasticmachine]

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

[elasticmachine]

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

[stratoula]

@vitaliidm I am sorry I am not very familiar with your code. Why are you using the unified search to render the ESQL editor and not immediately the editor?

As it is done in x-pack/plugins/stack_alerts/public/rule_types/es_query/expression/esql_query_expression.tsx

The editor is on it own plugin so it should be used instead of the unified search component.

[vitaliidm]

@stratoula

We are already using unified search component in our rule form:

kibana/x-pack/plugins/security_solution/public/common/components/query_bar/index.tsx

Line 16 in 361f92e

import { SearchBar } from '@kbn/unified-search-plugin/public';

for various rule types: query, new terms, threshold, etc. Since this component(unified search SearchBar) supports ES|QL and we got a lot of Security Solution logic build on top of SearchBar from '@kbn/unified-search-plugin/public' in this security_solution/public/common/components/query_bar/index.tsx. And we use other functionality that exist in the unified search component, not only query input, but filters as well. So if any of this will be added for ES|QL we would have support of it, instead of building our own in Security

Thats why, the decision was to use the same component, instead of importing new one and integrate it into the Security Solution.

[stratoula]

I don't think we are going to add filters in ES|QL as filtering is already provided in the language. Unified search offers the editor but only as part of it (if you have the dataview picker and click Try it).

I would like to avoid using the unified search for rendering only the editor because then if we need more customizations (as the one you are proposing here) that have nothing to do with the unified search component then we need to pass all these props to unified search.

Is it a big change for you to render the editor instead for this case? We can sync and check it together if you want.

[vitaliidm]

I don't think we are going to add filters in ES|QL as filtering is already provided in the language. Unified search offers the editor but only as part of it (if you have the dataview picker and click Try it).
I would like to avoid using the unified search for rendering only the editor because then if we need more customizations (as the one you are proposing here) that have nothing to do with the unified search component then we need to pass all these props to unified search.
Is it a big change for you to render the editor instead for this case? We can sync and check it together if you want.

If the only concern are customizations, if any new arise, we can reconsider to use ES|QL text editor directly again.
But at this point, I don't anticipate any new ones. We pretty much happy to be consistent with unified search

For us, we would like to be synchronized with the functionality available in unified search component, as this something we are getting for free and don't need to re-implement on our side. For example: selecting languages, using filters, using saving queries and so on. Instead of supporting 2 components, where one of them already built-in in another and available inside it.

Similarly, ES|QL also used in timeline: #166764, within unified search component, so it's not a unique use case

Happy to sync if needed

[stratoula]

We synced offline, it is actually a usage of unified search (they want to click the editor and expand it exactly as it happens in Discover) so this property makes sense.

In the future if we decide to do more customizations we might need to organize the editor customization properties in an object property but I think it is ok for now.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 21302ae

Failed CI Steps

• FTR Configs #24

Test Failures

• [job] [logs] FTR Configs #24 / APM API tests alerts/transaction_error_rate.spec.ts basic no archive transaction error rate alert create rule with kql query "after all" hook for "shows alert count=1 in opbeans-node service"

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	13.0MB	13.0MB	+150.0B
textBasedLanguages	148.7KB	148.7KB	+19.0B
unifiedSearch	215.2KB	215.3KB	+111.0B
total			+280.0B

History

• 💚 Build #165376 succeeded 7bb68e1
• 💔 Build #165337 failed ab7e499
• 💛 Build #165176 was flaky 361f92e
• 💔 Build #164993 failed 11b185a
• 💔 Build #164964 failed 857e6f8

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @vitaliidm

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.11

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation