Replace WzSearchBar component

[Desvelao]

This pull request is expected to merge after #5363

Description

This pull request replaces the usage of WzSearchBar with the new one.

Changes:

• Replace the search bar in the following sections:
  • Agent selection modal

  Adapt the external filters

  • Agent section

  Adapt the external filters
  Rename the name of the sessionStorage property from agents_preview_selected_options to wz_page_agents_search_bar_query and change the saved value. This is used to communicate from other sections with the search bar. Renaming avoids errors when the users upgrading due to the change in the schema of saved value.

  • Clean
    • Remove removeFilters props in the AgentsTable component. Adapt AgentsPreview render.
    • Remove unused file: public/controllers/overview/components/select-agent.js

TODO

Issues Resolved

Part of #4312

Evidence

Agent selection modal

Agents section

Test

⚠️ It is recommended to test some frequent queries in the section where the search bar was replaced. We should use a real Wazuh manager in 4.5.0 or 4.4.x as possible.

Tests
Agent selection modal - The query input should filter the data
Agent selection modal - Change the sort field should fetch the data taking into account this order
Agent selection modal - Change the sort direction should fetch the data taking into account this order
Agent selection modal - Change the current page should fetch the data taking into account this order
Agent selection modal - Change the page size should fetch the data taking into account this order
Agent selection modal - Clicking on a group label should add a query to the search bar and fetch data with that query
Agent section - The query input should filter the data
Agent section - Change the sort field should fetch the data taking into account this order
Agent section - Change the sort direction should fetch the data taking into account this order
Agent section - Change the current page should fetch the data taking into account this order
Agent section - Change the page size should fetch the data taking into account this order
Agent section - Export to CSV should use the filters
Agent section - Clicking on a group label should add a query to the search bar and fetch data with that query
Agent section - Clicking on a status value of visualization in Status panel should add a query input to the search bar and fetch data with the query
Agent section - Clicking on a status value of the indicator in Details panel should add a query input to the search bar and fetch data with the query
Agent section - Go to Modules directory and clicks on an agent status value should redirect to the Agents section and add a query input to the search bar and fetch data with the query

Check List

• All tests pass
  • yarn test:jest
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[asteriscos]

While testing the search bar I found a few issues:

Clicking the refresh button does not update the query status if the input changes. Instead, it uses the previous search parameters. If the user press the "enter" key, then it does update the state.

This also happens if the selected columns change.

If the search input is empty, it doesn't show the Apply Search in the available suggestions. An empty input is still a valid search.

If the user makes a generic search without a date format throughout all the available fields, which includes a Date format field, the API returns a format error.
Maybe date fields should not be used when a generic search is made.

[Desvelao]

While testing the search bar I found a few issues:

Clicking the refresh button does not update the query status if the input changes. Instead, it uses the previous search parameters. If the user press the "enter" key, then it does update the state.

This also happens if the selected columns change.

If the search input is empty, it doesn't show the Apply Search in the available suggestions. An empty input is still a valid search.

If the user makes a generic search without a date format throughout all the available fields, which includes a Date format field, the API returns a format error. Maybe date fields should not be used when a generic search is made.

The integration of the search bar in the Agents section is problematic due to the possibility to force refreshing the request data, which was not contemplated that input or selected columns could vary. In this case, we should extract the transformation of the input query to the API query language out of the search bar.

The problem with the search term with the date fields should be discussed. I think removing the date fields of the search it is not a good approach because the user can not search in these fields using the search term mode of the search bar.

[Desvelao]

Clicking the refresh button does not update the query status if the input changes. Instead, it uses the previous search parameters. If the user press the "enter" key, then it does update the state.

I am working around this problem. It could need some refactoring or extracting the generation of the Wazuh API parameters out of the search bar.

If the search input is empty, it doesn't show the Apply Search in the available suggestions. An empty input is still a valid search.

I added the search suggestion when the input is empty.

This also happens if the selected columns change.

The current behavior in the Agents section doesn't redo the request if the selected columns are changed. The request included all the available fields. Enable/disable the columns only adds or remove the column to the table.

If the user makes a generic search without a date format throughout all the available fields, which includes a Date format field, the API returns a format error. Maybe date fields should not be used when a generic search is made.

I was researching this problem and we will need to talk with the API coworkers. I did some researching here: #4312 (comment)

[Desvelao]

Clicking the refresh button does not update the query status if the input changes. Instead, it uses the previous search parameters. If the user press the "enter" key, then it does update the state.

I am working around this problem. It could need some refactoring or extracting the generation of the Wazuh API parameters out of the search bar.

Definitely, due how the component of the Agents section, I will need to extract the generation of the API request out of the search component.

I got to solve some problems, but modifying the visible columns meanwhile, the search bar input is in search term mode, if clicking on the Refresh button, causes the API request uses the previous selected fields instead of the new ones.

[Desvelao]

Update

I refactored the search bar component and now, the current implementations are managing when the user input changes without using the Search suggestion or pressing the Enter key and clicking on the Refresh button on the Agents section.

This enables the Refresh button in the Agents section to take into account the new user input instead of the previous one. For another hand, this behavior causes a bug if using the Export formatted button that should take into account the previous search which is the data that is displayed in the table.

The Agents section has a particular implementation, we should discuss what is the expected behavior, implement it in the reusable TableWzAPI component, and replace the current implementation in the Agents section with the enhanced TableWzAPI. This approach will centralize the behavior and remove the differences between components that seem to be similar.

[github-actions]

Code coverage (Jest)	%	values
Statements	10.01%	( 3735 / 37287 )
Branches	5.66%	( 1638 / 28922 )
Functions	8.99%	( 834 / 9275 )
Lines	10.11%	( 3613 / 35713 )

[Desvelao]

Problem

I am working into replacing the search bar in the Modules/MITRE ATT&CK/Intelligence section and I found a problem.

This section has a main search bar, that searches in all the available fields of the resources the input. Under the hoods, this does an API request:

GET /mitre/{resource}?search={search_bar_input}&limit=5

for each MITRE ATT&CK resource.

Using this search bar, displays a count of results. If for a resource there is more than the 5 elements, then the See more button is displayed. Clicking on this button causes a redirection to the resource view, that should pass the filters and the equivalence query in the search bar input. The search query parameter is not supported, so the API query should be translated to the usage of q. So, it is needed to specify each field to search the user input. If we define the fields displayed in the tables, they are name, description and name, there are less results foudn that using search. This means that others fields could match with the user input. Adding all the fields, should solve the problem, but in this case when the user is redirected, the new search bar will display an error because the fields are not supported in the validation of the search bar.

We should discuss how to solve this problem.

The current solution was restricting the field to the displayed in the tables: description, external_id and name. This approach will not be able to find resources whose match is in another field.

[Desvelao]

This pull request is closed in favor to that replaces the search bar and table components by the reusable TableWzAPI component:

• Replace search bar on Explore agent modal #5447
• Replace search bar on Agents #5452