Feed the suggestion field for the new search bar

[Desvelao]

Wazuh	Elastic	Rev	Security
4.x	7.x	4xxx	Basic, ODFE, Xpack

Browser
Chrome, Firefox, Safari, etc

Description

The new search bar component uses the q query parameter. This displays suggestions for the available fields that in the current WzSearchBar component, they are defined and maintained statically.

We would want to reduce the manual maintenance of this.

We could use the Wazuh API specification to get this data. The fields that are supported by q are not included in the API specification. In a meeting with the framework team, I asked about them, and they told me to use the example response because the field name follows a defined schema, and they are similar to the obtained response.

Some approaches to get and digest the data to feed the new search bar component are:

• Realtime (best solution)
• Generate the required data and add it to each plugin build.

This approach is used currently to feed the API Console for example.

[Desvelao]

Research

I was following the approach to generate a pre-digested file to feed the new search bar component.

This is done through a script that can be used to save the results to a file that could be used by the new search bar component.

Script: generate-api-q-fields-endpoints.js.zip

This script uses the swagger-client dependency that is not included in the current plugins, to work you should install it. From the root of the plugin, run:

yarn add -D swagger-client

Combining the generation of data with the new search bar, we could get the field suggestions display all the supported fields of q query parameter, even there are more than the current WzSearchBar is displaying:

The current plugins get data from the API specification and save it to common/api-info/endpoints.json, so I think we could add the fields supported by the q query parameter to the same file and not create a new one. Due to there being an issue to refactor how the data of common/api-info is obtained #5036, I think we should obtain and merge the fields of q to the same file.

[Desvelao]

I moved this issue to on hold state, because the solution is a POC based in a workaround.

[ArielIvanOjeda]

Hi Team, any updates on this?

[Desvelao]

Hi @ArielIvanOjeda ,

this issue is on hold because the workaround to get the available fields in each API endpoint doesn't match in some use cases. For example, some current use cases of search bars should suggest more fields that got through the workaround. After seeing this problem, I moved the issue to hold. So for now, they will have to be maintained manually.

Maybe we should extend the analysis for each use case, and evaluate the results.

I am not sure why are you asking for this issue, @ArielIvanOjeda, but if your question is related to some missing field suggestions, the implementation of the new search bar added some fields that are not included in the previous search bar. The new search bar uses the fields available in the q query parameter, this doesn't display other query parameters.