### AppConfig

AppConfig will be a new service inside Platform6. Extending the standard `AbstractServiceConfigurationItem`.

An AppConfigItem extends the default `AbstractServiceConfigurationItem` with:
- `key`, the configuration key
- `value`, the configuration value
- `type`, the class name of the value

In the DSL here are the available supported types :
- BOOLEAN
- INTEGER
- LONG
- DOUBLE
- FLOAT
- BYTE
- UUID
- DATE
- CHARACTER
- ZDT
- STRING

:::danger
:question: This type was based on the value type while calling the `save` method of the DSL. Should we restrict the available type in the UI?
>YES
:::

#### Edition

When editing an AppConfig item, show a form with the `key`, `value`, `type`

#### Override

To override a appconfig, the appconfig must be associated to an installedapp and click on a specific button on the actions of the line.

This open a form :
- Name
- Description
- default value
- value

:exclamation: Only the `value` column should be editable.

On save:
- do security checks on Read/Write mode
- the key must be preffixed by "`__.`"

> **Example:**
> For an application `appKey`
> {"key": "__.appKey.foo.enabled", "value": "true", "type", "Boolean", "appKey": ""}

#### List

Display:
- actions
- view
- edit (if app under dev || appKey=="")
- duplicate (should copy the context appKey to the new item)
- delete(if app under dev || appKey=="")
- override (if app installed)
- reset (if app installed and overrided))
- appKey
- name
- key
- type
- defaultValue
- value

filter:
- only ContentMode != HIDDEN are displayed (if app installed)
- __. entries should not be displayed

Action:
- override / reset (only if Content.MODE != READONLY)

### Application

#### Definition

With the new AppConfig service, we must be able to select that serviceItems to be bundled inside an application.

Those items should also be synchronized using P6Sync.

#### Read

In order to access the application configuration you have to use the AppConfig service or the AppConfig DSL. It will search for the configuration key inside the configuration override and if missing inside the application default configuration. We must take the type from the default entry.

#### AppConfig DSL

New methods:

- list(String appKey?), retuns a Map<String, Object> of all AppConfig items of the given appKey. The value will be the overridedValue || defaultValue.

- exists(appKey?, key) : boolean

Method list:
- get(appKey?, key) => TypedValue
- override(appKey?, key, value)
- list(appKey?)
- exists(appKey?, key): boolean

### Application Jobs

Update the *AbstractService* to add two new methods:
- saveConfig(String appKey)
- applyConfig(String appKey)

#### Uninstall Job

When uninstalling an application, inside the `UninstallJob` start by calling for every service (using the CMB) with the action "saveConfig". For now only the RouteService will have extra configuration to save. We can save time calling only this service via CMB but we should not forget to add the service call if we implement the save method inside another service.

The service will provide a configuration (compatible with the format defined bellow):

_.appKey.service.<serviceName>.<itemName>.property=value

For example:

_.p6_demo.service.routes.BlockchainEventHandler.autoStart=false

The idea behind the "_" prefix is to mark a property as computed, and therefore hide it in the edition grid.

When generated, the configuration will be saved using the AppConfig service the same way it will be done using the UI.

#### Install Job

After installing an application, we have to call every service (or only the routes one cf. below) with the action "applyConfig".

The service will call the AppConfig service to retrieve the specific configuration. The response will be:

_.p6_demo.service.routes.BlockchainEventHandler.autoStart=false
_.p6_demo.service.routes.RoutingRuleDispatcher.autoStart=false

The service will have to parse this configuration entries to configure the service items (ie. set autoStart to true or false)