Skip to content

Move vis_type_xy enablement config to advanced settings #77186

@nickofthyme

Description

@nickofthyme

Describe the feature:
Currently the vis_type_xy plugin is enabled via a kibana.yml config value.

export const config = {
schema: schema.object({ enabled: schema.boolean({ defaultValue: false }) }),
};

Then used in the vis_type_vislib plugin setup to prevent registering the corresponding vislib type (i.e. line, area, histogram).

// if visTypeXy plugin is disabled it's config will be undefined
if (!visTypeXy) {
const convertedTypes: any[] = [];
const convertedFns: any[] = [];
// Register legacy vislib types that have been converted
convertedFns.forEach(expressions.registerFunction);
convertedTypes.forEach((vis) =>
visualizations.createBaseVisualization(vis(visualizationDependencies))
);
}

Note: The empty array for future convertedTypes

Block registration of vis types in vis_type_xy plugin

const visTypeDefinitions: any[] = [];
const visFunctions: any = [];
visFunctions.forEach((fn: any) => expressions.registerFunction(fn));
visTypeDefinitions.forEach((vis: any) =>
visualizations.createBaseVisualization(vis(visualizationDependencies))
);

Instead, this logic should be driven from advanced settings.

Description of advanced setting should include lack of support for split chart aggregations.

Additional Context
This replacement of vislib will not be changing the existing visualization saved objects and hence both vis_type_vislib and vis_type_xy cannot register the same three visualization types (i.e. line, area, histogram).

Metadata

Metadata

Labels

Feature:NP MigrationFeature:VislibVislib chart implementationTeam:VisualizationsTeam label for Lens, elastic-charts, Graph, legacy editors (TSVB, Visualize, Timelion) t//

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions