Original message from @FrankHassanabad
In the legacy platform we have a isEnabled function
isEnabled(config: Legacy.KibanaConfig) {
where we define our plugin and we can use that if we want to hide our plugin behind a feature flag during development such as actions and alerting is doing at the moment.
In the new platform it looks like we have a cool automatic feature where we don't need to define an isEnabled function but rather the new platform just uses our id from kibana.json automatically:
https://github.com/elastic/kibana/blob/master/src/core/server/config/config_service.ts#L104
And if we want to disable a plugin we put our id from kibana.json inside of our kibana.yml with enabled set to false if we want to turn off that plugin.
For example:
inspector.enabled: false
However, how do we flip the logic within a new platform plugin to disable our plugin by default unless some one enables explicitly to true within kibana.yml to replicate the same feature flag behaviors we have been using in plugins such as actions and alerting?
Proposed solution
I'd expect that plugins can specify a default value for enable flag during schema declaration
export const config = {
schema: schema.object({
enabled: schema.boolean({ defaultValue: false })
})
}
It turned out that platform ignores those default values and uses raw config instead https://github.com/restrry/kibana/blob/841abd1162f1eb6aaebf27d004c92e8344636d91/src/core/server/config/config_service.ts#L108
At this stage we already have plugins validated config and can access enabled value.https://github.com/restrry/kibana/blob/841abd1162f1eb6aaebf27d004c92e8344636d91/src/core/server/plugins/plugins_service.ts#L146-L150
const isEnabled = validatedConfig ? validatedConfig.enabled : config.get(enabledPath);
Original message from @FrankHassanabad
In the legacy platform we have a isEnabled function
isEnabled(config: Legacy.KibanaConfig) {where we define our plugin and we can use that if we want to hide our plugin behind a feature flag during development such as actions and alerting is doing at the moment.
In the new platform it looks like we have a cool automatic feature where we don't need to define an isEnabled function but rather the new platform just uses our id from kibana.json automatically:
https://github.com/elastic/kibana/blob/master/src/core/server/config/config_service.ts#L104
And if we want to disable a plugin we put our id from kibana.json inside of our kibana.yml with enabled set to false if we want to turn off that plugin.
For example:
inspector.enabled: falseHowever, how do we flip the logic within a new platform plugin to disable our plugin by default unless some one enables explicitly to true within kibana.yml to replicate the same feature flag behaviors we have been using in plugins such as actions and alerting?
Proposed solution
I'd expect that plugins can specify a default value for
enableflag during schema declarationIt turned out that platform ignores those default values and uses raw config instead https://github.com/restrry/kibana/blob/841abd1162f1eb6aaebf27d004c92e8344636d91/src/core/server/config/config_service.ts#L108
At this stage we already have plugins validated config and can access
enabledvalue.https://github.com/restrry/kibana/blob/841abd1162f1eb6aaebf27d004c92e8344636d91/src/core/server/plugins/plugins_service.ts#L146-L150