Fixed Inventory checks table filters by stats

[Machi3mfl]

Description

Hi Team, This PR fixes the behavior when the Inventory Stat is clicked.
Closes #4952

Test case

• When the Inventory Stat is clicked the Check table must be filtered

Peek.2022-12-14.13-36.mp4

Tests

1. Scenario The user can add a filter by clicking on the result count indicator (Pass) of the Security configuration assessment
   policy checks
   Given SCA data is available
   When the user is seeing the table of checks of a Security configuration assessment
   policy
   And the user clicks on any result count indicator
   Then a filter must be added to the search bar
   And the table should be filtered by the added filter

2. Scenario The user can add a filter by clicking on the result count indicator (Fail) of the Security configuration assessment
   policy checks
   Given SCA data is available
   When the user is seeing the table of checks of a Security configuration assessment
   policy
   And the user clicks on any result count indicator
   Then a filter must be added to the search bar
   And the table should be filtered by the added filter

3. Scenario The user can add a filter by clicking on the result count indicator (Not applicable) of the Security configuration assessment
   policy checks
   Given SCA data is available
   When the user is seeing the table of checks of a Security configuration assessment
   policy
   And the user clicks on any result count indicator
   Then a filter must be added to the search bar
   And the table should be filtered by the added filter

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

[Desvelao]

review

Tests

Legend:
🟢 Pass
🟡 Warning
🔴 Fail

Results:

Scenario	Result
1	🟢
2	🟢
3	🔴

Details:

Scenario 1 - 🟢

Scenario 2 - 🟢

Scenario 3 - 🔴

I found a problem by clicking on the Not applicable result count indicator, the table doesn't display any results.

I reviewed the request done when adding this filter and it uses the result query paramater with not applicable value. This value is not the correct one to get the expected checks.

If we review the value for any check that the UI displays as Not applicable, we see this is an empty string.

So, we expected if we change the value of the result query parameter to an empty string, we could get the expected results. By my tests, it is not working, so I guess the Wazuh API could not be expecting this case. We should consult it with the @wazuh/framework team.

In previous versions (ex: 4.3.10), this worked correctly and this was because in that version, all the checks are obtained and the filter are managed in the frontend.

[Desvelao]

review

Tests

Legend: green_circle Pass yellow_circle Warning red_circle Fail

Results:

Scenario Result
1
2
3
Details:

Scenario 1 -
Scenario 2 -
Scenario 3 -
I found a problem by clicking on the Not applicable result count indicator, the table doesn't display any results.

I reviewed the request done when adding this filter and it uses the result query paramater with not applicable value. This value is not the correct one to get the expected checks.

If we review the value for any check that the UI displays as Not applicable, we see this is an empty string.

So, we expected if we change the value of the result query parameter to an empty string, we could get the expected results. By my tests, it is not working, so I guess the Wazuh API could not be expecting this case. We should consult it with the @wazuh/framework team.

In previous versions (ex: 4.3.10), this worked correctly and this was because in that version, all the checks are obtained and the filter are managed in the frontend.

We had a meeting with @davidjiglesias and maybe we could get a workaround:
Use status query parameter instead of result.

For another hand, we could remove the empty string as a possible value of result filter so the users can't filter and get unexpected results.

We should review the suggestions for status too.

[Machi3mfl]

Fixed Not Applicable filter using the status field

Peek.2022-12-16.10-28.mp4

The solution applied was mentioned in comment

[yenienserrano]

LGTM

Pass

Fail

Not applicable

[github-actions]

Code coverage (Jest)	%	values
Statements	8.68%	( 3210 / 36962 )
Branches	4.43%	( 1271 / 28689 )
Functions	7.59%	( 696 / 9167 )
Lines	8.75%	( 3097 / 35382 )

[chantal-kelm]

CR: ✅
Test: ✅

[Desvelao]

review

✔️ code
✔️ test

Tests

Legend:
🟢 Pass
🟡 Warning
🔴 Fail

Results:

Scenario	Result
1	🟢
2	🟢
3	🟢

Details:

Scenario 1 - 🟢

Scenario 2 - 🟢

Scenario 3 - 🟢

[github-actions]

The backport to 4.4-7.16 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.4-7.16 4.4-7.16
# Navigate to the new working tree
cd .worktrees/backport-4.4-7.16
# Create a new branch
git switch --create backport-4999-to-4.4-7.16
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6e8c94263c5faeb0d02b2b38786d4026b20fb137
# Push it to GitHub
git push --set-upstream origin backport-4999-to-4.4-7.16
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.4-7.16

Then, create a pull request where the base branch is 4.4-7.16 and the compare/head branch is backport-4999-to-4.4-7.16.

[github-actions]

The backport to 4.4-2.4-wzd failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.4-2.4-wzd 4.4-2.4-wzd
# Navigate to the new working tree
cd .worktrees/backport-4.4-2.4-wzd
# Create a new branch
git switch --create backport-4999-to-4.4-2.4-wzd
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6e8c94263c5faeb0d02b2b38786d4026b20fb137
# Push it to GitHub
git push --set-upstream origin backport-4999-to-4.4-2.4-wzd
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.4-2.4-wzd

Then, create a pull request where the base branch is 4.4-2.4-wzd and the compare/head branch is backport-4999-to-4.4-2.4-wzd.