Global menu

[gdiazlo]

Introduction

This UX redesign tier 1 scope involves mostly a new general menu for the whole interface.

Now that we have control over the complete dashboard, we want to improve the user experience, making it easier to access Wazuh features. Our first step will be to create a new menu experience in line with what the platform is designed to work with: the left navigation drawer.

Our current menu is embedded into our main application in the top bar:

We want to incorporate this accesses into the global navigation drawer, transforming the current look (on the left) to something like:

Of these, we want to pursue the 1st one, as it allows us to implement the global navigation drawer in a simple and fast pace manner, and allows us to evolve the main plugin with time, iteratively, instead of a big bang devel approach, unlike option 2 and 3.

It is important that we leverage the built-in styles and looks so that our menu can evolve with the new upstream changes which are on their way (for example opensearch-project#4298).

We must customize the icons for each category. The UI library provides a set of icons we could use.

It's also important to study what would happen in the case of newer applications arriving from upstream that use the same categories as we propose here.

Functional requirements

• Users must be able to navigate to the main page of each module by accessing it using the global navigation drawer.

Non-functional requirements

• The health-check must not run on every navigation through the navigation drawer. It sould only run when neccesary.
• Background requests and state sharing must be kept at a minimum.
• We must use the i18n framework, allowing future translation.
• We must use the accessibility options built in the platform.
• We must support dark and light themes.
• We must support testing with Cypress or other UI testing frameworks (use identifiable selectors, etc.)

Plan

• Propose and evaluate different designs #93
• Integrate our menu into the platform global navigation drawer #94
• Update the documentation after the new menu

[Desvelao]

Design

Following the approach: #83 (comment)
Base development branch: feat/83-move-menu-items-to-applications

A plugin registers each application in the side menu. The initial solution uses the same plugin, and we don't consider to be needed another plugin to register the application in the side menu because it creates more complexity. Each application mounts the monolith application whose entry point is modified to display the expected view.

[JuanGarriuz]

Tabs in Server Management - RBAC don't work

[yenienserrano]

When you want to navigate between the Endpoint security, Thread intelligence, Security operations and Cloud security modules and go through the heath check instead of redirecting to the desired view, it redirects to the overview.

On the other hand, changing views is changing the plugin, as the URL changes and the application takes longer to load the views, so it slows down the application and in my environment it doesn't have much data to load.

[Desvelao]

Tabs in Server Management - RBAC don't work

Fixed here: wazuh/wazuh-dashboard-plugins@bc7739f

[Desvelao]

Meeting

Discussions

• What to do with global breadcrumb?
• API hosts and valid index patterns are updated when opening or closing the current menu. Should its behavior be kept? And how?
• Visibility of applications related to the current modules that depend on API host configuration, and selected agent. Should it be supported? How should we implement it?
• Name of the platform categories
• Menu for agent
  
• Should the tabs related to other applications be removed?
  • current section: Settings
    
  • current section: Tools
    
• Global menu #83 (comment)
• When the user accesses an application, get a new API token. This means if the user is changing between applications, he/she will get new tokens.

Decisions

• Global breadcrumb: adapt to the managed by the platform
• Research the impact of: API hosts and valid index patterns are updated when opening or closing the current menu. Should its behavior be kept? And how?
• Visibility of applications related to the current modules that depend on API host configuration, and selected agent. Should it be supported? How should we implement it? Yes
• Remove OpenSearch from OpenSearch Dashboards and plugins categories
• Menu agent: keep (only change the redirections)
• Remove tab navigation for the Settings and Tools apps.

[Desvelao]

Changes

• Create new applications in the side menu:

Category	Name	Section in monolith plugin
Management	Modules	Settings > Modules
Management	Miscellaneous	Settings > Miscellaneous

Notes:
Settings > Miscellaneus should be moved to Configuration
Modules app only contains the visibility of some applications. This should be refactored to support all the applications.

[Desvelao]

Changes

• Removed navigation by tabs in Settings wazuh/wazuh-dashboard-plugins@d68459f
• Removed navigation by tabs in Tools wazuh/wazuh-dashboard-plugins@ea05283

[JuanGarriuz]

Server Management Issues

Groups

When we click on the eye icon to navigate to Agent-preview, we go to /app/wz-groups#/agents?_g=(filters, using monolithic logic. The function that works over the eye button is showAgent() which works like:

The expected result is to navigate to the Endpoints summary:

But keep into Groups

We can find that code in → plugins/main/public/controllers/management/groups.js
That code modified the URL after "#" to navigate a new web section, but it doesn't work in the new menu bar logic, because we navigate across the menu bar.

To fix it, there are 2 main branches; create a new function that works in all redirection code lines, or change old logic code lines with a HREF.

Statitics

When we click on the settings button, we go to /app/wz-statistics#/settings?tab=configuration&category=statistics, using monolithic logic. The function that works over the button is navigateToModule() which works like:

The expected result is to navigate to Configuration:

But keep in Statistics

We can find that code in → plugins/main/public/controllers/management/components/management/statistics/statistics-overview.js
That code modified the URL after "#" to navigate a new web section, but it doesn't work in the new menu bar logic, because we navigate across the menu bar.

To fix it, there are 2 main branches; create a new function that works in all redirection code lines, or change old logic code lines with a href.

Monitoring

When we click on the Agents button, we go to /app/wz-cluster#/agents-preview/?_g=(filters:, using monolithic logic. The function that works over the button is a href.

The expected result is to navigate to Configuration:

But keep in Statistics

We can find that code in → plugins/main/public/controllers/management/monitoring.js
That code modified the URL with a href. but that means that there are at least 3 different ways to navigate over the different parts of the app.

To fix it there are 2 main branches; create a new function that works in all redirection code lines, or change old logic code lines on the href.

Conclusion

If we fix those changes all navigates code lines to hrefs the code will be too much dirt, making it more difficult to fix bugs in the future, and making the code less reusable.
Conversely, it means that we have to take more time to make reusable and cleaner code.

[yenienserrano]

Research the impact of: API hosts and valid index patterns are updated when opening or closing the current menu. Should it behavior keep and how?

Requests are made to update the index pattern and apis selectors.
This is not very reliable because if the user adds an index pattern or a new api and opens the selector, he will not see the changes until he opens the menu or refreshes the page.
With the index pattern it would only affect if you have more than 1 window open with Wazuh, because if the user only handles 1 window when adding an index pattern and then navigates to another view, the requests would be executed when mounting the component.
For me, it is better to add to the documentation that after adding a new api or index pattern you have to restart the browser, and save us from making those requests every so often or when the user makes a specific action.
We can also use the onMouseEnter function to execute the request when the user puts the mouse over the selector, but this may cause unnecessary requests.

[Desvelao]

Changes

• Create new applications in the side menu:

Category	Name	Section in monolith plugin
Endpoint security	Overview	Modules directory

[Desvelao]

Meeting

Discussions:

• Global menu #83 (comment)

We can also use the onMouseEnter function to execute the request when the user puts the mouse over the selector, but this may cause unnecessary requests.

[Desvelao]

Meeting

Current status

• Problems

  • Share state
    • Redux store and singleton are reset when changing applications due to a page refresh when the application is mounted
    • Loop in the health check
    • When you change the application quickly, sometimes it gives you an error in the console and shows you the previous view to the currently selected one.
    • Sometimes when you want to enter to some module, it always redirects you to the Endpoints summary. Modules - Endpoints summary
    • Problems with the tabView in the url, in the views you should change the value but then return to the previous value.
  • Redirections to applications

• Comment

  • Applications visibility:
    • configuration
    • Selected API host
    • selected Agent (affecting to old modules)
  • UX problems:
    • Too many applications
    • Switching application is slow

Action items

• Rename built-in menu categories (OpenSearch Dashboards and Management). This should be done in the current process to generate the Wazuh dashboard package.