wazuh-dashboard-plugins
wazuh-dashboard-plugins copied to clipboard
Custom branding: centralize the plugin's settings
Description
The data related to the plugin settings definition are distributed in different files and there are some repetitive tasks and bad practices. Adding a new setting has a high cost in development time.
Goal
- Centralize the definition of the plugin's settings, so every side of the app reads the settings from the same source.
- Reduce the future cost, in time, to add or remove plugin settings.
Tasks
- [x] Define a schema of properties to manage the current plugin logic
- [x] Adapt the affected sections of the plugin to use the new plugin setting definition, dynamically.
- [x] Default configuration file
- [x] Configuration in
Settings/Configuration
- [x] Refactor the form
- [x] Create new hooks to manage the form state
- [x] Refactor the input components to do them uncontrolled.
- [ ] Sort the plugin setting categories
- [x] Tests
- [x] Default configuration file
- [x]
useForm
hook - [x]
InputForm
component
Automatic management of the plugin's settings
We're centralizing the plugin settings definitions in a single source.
These definitions are used by:
- the generation of the initial/default plugin configuration file.
- the
Settings/Configuration
UI section.
Both sections have been updated to use this new centralized mechanism to read the plugin's settings. This work will simplify the additions of new settings related to this white-labeling issue and future developments.
Objective
- Reduce and simplify the time to add or remove a new setting. This will reduce the cost in time when we need to add or remove settings in the future.
- Dynamically generate the sections that depend on the plugin's settings, by importing the settings and their descriptions from the centralized plugin's setting definitions file.
For example, a new setting is added in the definitions file, then:
- It is included in the initial configuration file (wazuh.yml) automatically, at plugin's start.
- The UI
Settings/Configuration
section reads the settings and generates the form dynamically.
Implementation
The settings are defined with a specific structure, as follows:
Property | Definition |
---|---|
title |
Define the text displayed in the UI. |
description |
Description. |
category |
Category. |
type |
Type of setting. |
default |
Default value. |
defaultHidden? |
Value used when there is no user value. |
isConfigurableFromFile? |
This can be customized in the plugin configuration file. |
isConfigurableFromUI? |
This can be customized from the UI. |
requiresRunningHealthCheck? |
Require the health check of the plugin is run. |
requiresReloadingBrowserTab? |
Require to reload the browser tab. |
requiresRestartingPluginPlatform? |
Require to restart the plugin platform service. |
options? |
Options to define the possible values, requirements, or extra data. This could be expanded. |
uiFormTransformChangedInputValue? |
Transform the input value. The result is saved in the form of Settings/Configuration . |
uiFormTransformInputValueToConfigurationValue? |
Transform the configuration value or default as initial value for the input in Settings/Configuration |
uiFormTransformConfigurationValueToInputValue? |
Transform the input value changed in the form of Settings/Configuration and returned in the changed property of the hook useForm |
validate? |
Validate the value. Return a string if there is some validation error. |
validateBackend? |
Validate the value in the related endpoints. Use schema of @kbn/config-schema package. |
Removed no longer used code
Some files were removed because of the centralization of the plugin settings definitions.
Adaptions
Adapted:
- The generation of the initial plugin configuration file is now made according to the centralized plugin's settings.
- The
Settings/Configuration
UI section has been updated:- The UI form has been updated.
- The search bar and filter by categories has been updated.
- Removed unnecessary components:
Categories
- Renamed the
validationOptions
tovalidate
- Added new properties to manage how the assets are stored:
- Define the relative target path of the plugin where the file will be stored
- Define the target filename
- Define the resolved URL which is exposed (public)
- Added new
options
type related to theeditor
input form.
- Added new setting property
Property | Required | Description |
---|---|---|
transformUIInputValue |
No | Transforms the value of the input HTML element |
This setting helps to transform the expected value for the settings of type switch
whose possible values are: true
or ""
that don't match with the current requirements of true
/false
(boolean).
Due to a requirement for a new feature, it is required to refactor the form and input components, so their state is controlled in the form parent component.
Tasks:
- [x] Refactor the form
- [x] Create new hooks to manage the form state
- [x] Refactor the input components to delegate their state to the parent controller.
Added tests for:
-
useForm
hook. - default configuration file.
-
InputForm
component.