Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User interface toggle for vulnerability evaluation status #6957

Closed
1 of 2 tasks
Tracked by #25479
Dwordcito opened this issue Aug 30, 2024 · 6 comments · Fixed by #6968
Closed
1 of 2 tasks
Tracked by #25479

User interface toggle for vulnerability evaluation status #6957

Dwordcito opened this issue Aug 30, 2024 · 6 comments · Fixed by #6968
Assignees
Labels
level/task Task issue type/enhancement Enhancement issue

Comments

@Dwordcito
Copy link
Member

Dwordcito commented Aug 30, 2024

Description

There are some vulnerabilities that have not been evaluated yet, therefore some fields are missing.
This issue aims to implement a toggle in the user interface to display the dispute/evaluation status using the wazuh.vulnerability.under_evaluation filter.

Vulnerabilities still under evaluation:
image

Tasks

  • Create a filter control that allows the user to filter wazuh.vulnerability.under_evaluation by true or false

    • This could be done by:
      • developing a new action button like the Explore agent selector
        image

      • or perhaps a new type of control in the "implicit filters" section of the search bar.
        image

  • Adapt Wazuh dashboard sample data to consider this case, so it can be easily tested.

Vulnerabilities dashboard

image

Vulnerabilities inventory

image

@asteriscos asteriscos added level/task Task issue type/change type/enhancement Enhancement issue and removed type/change labels Sep 2, 2024
@Tostti Tostti transferred this issue from wazuh/wazuh Sep 3, 2024
@Desvelao Desvelao self-assigned this Sep 3, 2024
@wazuhci wazuhci moved this from Backlog to In progress in Release 4.10.0 Sep 3, 2024
@Desvelao
Copy link
Member

Desvelao commented Sep 3, 2024

Proposition 1

This defines a form control in the same row of the search bar filters at the end with the ability to select an option to filter:

  • unset: no filter. This is the initial value.
  • yes: add a filter wazuh.vulnerability.under_evaluation: false
  • no: add a filter wazuh.vulnerability.under_evaluation: true

Clicking on the yes or no option adds a user filter to the search bar too. This causes the data related to the filter is displayed in two places. This approach is similar to the GitHub/Office 365 > Panel views when using the simple search bar.

image
image
image

@Desvelao
Copy link
Member

Desvelao commented Sep 3, 2024

Proposition 2

Add an editable filter near to the fixed filters. This approach reduces the occupped space from the propostion#1.

This needs changes in the data source to support this type of editable filters. Depending on the case, this filter could not be shared because this could not be present in the URL.

image
image
image

This is a POC, and the badge should have similar height of other filters. The selector is causing the badge height grows. The edition of filter could be done through a popover as the user filters.

@Desvelao
Copy link
Member

Desvelao commented Sep 3, 2024

Proposition 3

Usage of simple and advanced search bar. Similar to GitHub/Office 365 > Panel view.

image

GitHub > Panel simple alternative search bar

The simple alternative has filters for the most important fields.

The advanced alternative is the search bar as Discover application.

@Desvelao
Copy link
Member

Desvelao commented Sep 4, 2024

Proposition 4

Add a form control near to the fixed filters. This form control adds user filter with a controlledBy property to identify. The user filters should not include the filter. This allows the controlled filter is synced with the URL too.

The render could be similar to Proposition 2.

Image

This is a POC, the UI could need some enhancements.

If the controlled filter is rendered by the user search bar filters, when using the Disable all option the filter is kept on the URL meanwhile, if the controlled filter is not passed to the user search bar filter, using the Disable all option, the filter dissappear from the URL. The result is the same, the filter should be used, but it could have other unknown consequences.

@Desvelao
Copy link
Member

Desvelao commented Sep 5, 2024

In a recent meeting, we decided to avoid the addition of a UI control to set the filter related to wazuh.vulnerability.under_evaluation because this would create a different view of the search bar for this specific case breaking the consistency with other views and this is not desired at this moment.

To meet this need, we will add a new visualization that display data related to the evaluated and non-evaluated vulnerabilities. The user could click in these indicators, and the related filter should be added to the list of filters and the data is filtered taking into account the new filters.

The visualization should be something similar to:
Image

@Desvelao
Copy link
Member

Desvelao commented Sep 5, 2024

I created the visualization using the Visualize application

  • type: metric
  • aggregation: Filters
    • Filter1: wazuh.vulnerability.under_evaluation:false
      Label: Evaluated
    • Filter2: wazuh.vulnerability.under_evaluation:true
      Label: Pending

and I add it into the dashboard porting the visualization definition to the definition on the plugin.

Result:
Image

Notes:

  • Count label of aggregation was replaced by Evaluation because the dashboard where the visualization is added, has other indicators that use Severity count label.

@Desvelao Desvelao linked a pull request Sep 5, 2024 that will close this issue
6 tasks
@wazuhci wazuhci moved this from In progress to In review in Release 4.10.0 Sep 5, 2024
@wazuhci wazuhci moved this from In review to Pending final review in Release 4.10.0 Sep 16, 2024
@wazuhci wazuhci moved this from Pending final review to In progress in Release 4.10.0 Sep 18, 2024
@asteriscos asteriscos assigned asteriscos and unassigned Desvelao Sep 20, 2024
@Machi3mfl Machi3mfl self-assigned this Sep 23, 2024
@asteriscos asteriscos removed their assignment Sep 23, 2024
@wazuhci wazuhci moved this from In progress to Pending review in Release 4.10.0 Sep 26, 2024
@wazuhci wazuhci moved this from Pending review to Done in Release 4.10.0 Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
level/task Task issue type/enhancement Enhancement issue
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants