Open Dwordcito opened 2 weeks ago
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.
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.
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.
Usage of simple and advanced search bar. Similar to GitHub/Office 365 > Panel
view.
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.
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.
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.
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:
I created the visualization using the Visualize
application
Filters
wazuh.vulnerability.under_evaluation:false
Label: Evaluated
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:
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.
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:
Tasks
[ ] Create a filter control that allows the user to filter
wazuh.vulnerability.under_evaluation
bytrue
orfalse
This could be done by:
developing a new action button like the
Explore agent
selectoror perhaps a new type of control in the "implicit filters" section of the search bar.
[x] Adapt Wazuh dashboard sample data to consider this case, so it can be easily tested.
Vulnerabilities dashboard
Vulnerabilities inventory