Custom branding: centralize the plugin's settings

[Desvelao]

Description

The settings of the app are currently 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

• Define a schema of properties to manage the current plugin logic
• Adapt the affected sections of the plugin to use the new plugin setting definition, dynamically.
  • Default configuration file
  • Configuration in Settings/Configuration
• Refactor the form
• Create new hooks to manage the form state
• Refactor the input components to do them uncontrolled.
• Sort the plugin setting categories
• Add description to category.
• Tests
  • Default configuration file
  • useForm hook
  • InputForm component

[Desvelao]

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

[Desvelao]

• Renamed the validationOptions to validate
• 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)

[Desvelao]

• Added new options type related to the editor input form.

[Desvelao]

• 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).

[Desvelao]

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:

• Refactor the form
• Create new hooks to manage the form state
• Refactor the input components to delegate their state to the parent controller.

[Desvelao]

Added tests for:

• useForm hook.
• default configuration file.
• InputForm component.