Breaking changes in 7.10

To rename the Ingest Manger plugin to Fleet:

via #79406

Kibana plugins can no longer rely on their server code being automatically transpiled with Babel. The @kbn/plugin-helpers provide a build task that will transform a plugin’s server code to plain JS via Babel, but plugin authors can use a tool of their choosing to accomplish the same result.

via #79176 and #79379*

The following Ingest Manager API routes changed:

via #79193

The high-level search API SearchSource is now available on the server:

function async myRouteHandler(context, request, response) {
  const searchSource = await data.search.searchSource.asScoped(request);
  searchSource.createEmpty(); // API after calling `asScoped` matches the client-side service
}

via #78383

This release introduces the following search helpers:

via #78006

The refactoring includes the following changes:

via #77791

The data.search service now includes these explicit error types:

The new showError function can be used with these errors to show customized toast messages. Applications may choose to handle errors differently. However, the SearchTimeoutError error notification is shown regardless.

data.search.search(...)
   .catchError((e: Error) => {
       data.search.showError(e);
   }

via #77788

A className prop was added to the main container of the QueryStringInput component.

via #76848

KibanaRequest now has a uuid property, which is a UUID that uniquely identifies the request.

via #76822

IndexPattern.save has been replaced with IndexPatternsService.save.

via #76706

The FetchOptions type was removed—use the ISearchOptions type instead. The ISearchOptions signal option was renamed to abortSignal.

via #76538

The __LEGACY APIs have been removed from the data plugin’s client-side search service. Specifically, data.search.__LEGACY.esClient is no longer exposed, and the legacy elasticsearch-browser package has been removed from the repo. If you rely on this client in your plugin, we recommend migrating to the new elasticsearch-js client.

via #75943

Kibana Platform plugins can now read the status of their dependencies, their plugin’s default status, and manually override that status as reported to the end user and on the /api/status endpoint.

class MyPlugin {
  setup(core) {
    // Override default behavior and only elevate severity when elasticsearch is not available
    core.status.set(
      core.status.core$.pipe(core => core.elasticsearch);
    );
  }
}

via #75819

The behavior of how search requests timeout changed:

via #75728

The IndexPattern class now takes shortDotsEnable (boolean) and metaFields (string[]) as arguments. These were formerly provided by uiSettings

via #75717

The expressions plugin has removed its __LEGACY APIs, which were designed for internal use in Canvas. In the unlikely event that you rely on the expressions.__LEGACY namespace, you will need to copy the relevant code into your plugin before updating.

Also removed is the createKibanaUtilsCore helper from the kibana_utils plugin, which was only used in the legacy Expressions APIs.

via #75517

The getParamsFromSearchRequest helper changed to prepare for exposing SearchSource on the server. If your plugin relies on this helper, update the dependencies passed to it as follows:

       import { getSearchParamsFromRequest } from '../../../src/plugins/data/public';

       const params = getSearchParamsFromRequest(request, {
-          injectedMetadata: core.injectedMetadata,
-          uiSettings: core.uiSettings,
+          esShardTimeout: core.injectedMetadata.getInjectedVar('esShardTimeout') as number,
+          getConfig: core.uiSettings.get.bind(core.uiSettings),
       });

via #75368

The index pattern fields class has the following changes:

The index pattern field class has the following changes:

via #75185

The following Fleet (previously Ingest Manager) API routes changed:

All Ingest Manager routes with payload fields that were previously in reference to agent configs or package configs have been renamed to agent policies and package policies. For example configId → policyId, package_configs → package_policies.

The following Ingest Manager app routes changed:

The following Ingest Manager settings changed:

via #74914

The getSearchErrorType and the SearchError class have been removed from the static exports of the data plugin’s contract. If you rely on these, copy the code directly into your plugin. The SearchError interface is still exposed.

via #74607

The search.aggs service in the data plugin is now available on the server. The usage is the same as on the client, except that a scoped saved objects client must be provided on the server to retrieve the start contract:

const savedObjectsClient = savedObjects.getScopedClient(kibanaRequest);
// `aggs.asScopedToClient` will return the same contract as is available in the browser
const aggs = await data.search.aggs.asScopedToClient(savedObjectsClient);
const allAggTypes = aggs.types.getAll();

The calculateAutoTimeExpression method was removed from the setup contract, and now only exists on the data plugin’s start contract. The method was was not used in setup elsewhere in Kibana, so it was removed for simplicity.

In addition, the agg types registry changed and now accepts a provider function, which is used to inject dependencies. This might be needed in the agg type definition, specifically a getConfig function used to retrieve uiSettings:

const getMyAgg = ({ getConfig }) =>
  new MetricAggType({
    name: 'myAgg',
    expressionName: 'myAggFunction',
    getSerializedFormat: (agg) => ({ id: 'number' }),
    params: [
      {
        name: 'someParam',
        write: (agg, output, aggs) => ({
          const queryLanguage = getConfig('search:queryLanguage');
          ...etc
        })
      }
    ],
  });

// register the agg type provider
dataSetup.search.aggs.registerMetric('myAgg', getMyAgg);

via #74472

Route definitions can now specify the idleSocket timeout in addition to the payload timeout.

Resolves #73557.

via #73730

Kibana provides the new Elasticsearch client as a part of the Elasticsearch service on the server-side. The legacy client is deprecated on and subject for removal in 7.x. Reference the migration guide to refactor your code

via #73651

This PR allows gracefully extracting of the query string state, to be consumed by other services. You can now use the data.query.state$ observable and receive all state updates in one place.

data.query.state$.subscribe((queryState: QueryState) => {...})

This PR also adds the data.query.queryString service, allowing to you set the query string programmatically.

data.query.queryString.setQuery({query: 'abc', language: 'kuery'});

via #72093

This PR allows you to assign privileges to the Alerting framework when defining your feature in Kibana. When registering your feature, you can add a list of AlertTypes under your read and all keys of the privileges object, as such:

features.registerFeature({
      id: 'alertsExample',
      name: 'alertsExample',
      app: [],
      privileges: {
        all: {
          alerting: {
            all: ['example.always-firing', 'example.people-in-space'],
          },
        },
        read: {
          alerting: {
            read: ['example.always-firing', 'example.people-in-space'],
          },
        },
      },
    });

This specifies:

For example, an all user will be able to create an example.always-firing alert with the alertsExample as consumer. This will also automatically grant the user the right to create an example.always-firing alert from within Alerts management, where alerts is the consumer. This does not grant the user the ability to create an example.always-firing alert under any other consumer. For that, the specific consumer will have to grant the user explicit rights through their privilege system.

For example, if Uptime wanted to allow users to create an example.people-in-space alert inside of the Uptime solution, then they will have to do the following:

features.registerFeature({
      id: 'uptime',
      name: 'Uptime',
      app: [],
      privileges: {
        all: {
          alerting: {
            all: ['xpack.uptime.alerts.actionGroups.tls', 'example.people-in-space'],
          },
        },
        read: {
          alerting: {
            read: ['xpack.uptime.alerts.actionGroups.tls', 'example.people-in-space'],
          },
        },
      },
    });

This, assuming it’s added by Uptime, would grant uptime users the privilege to create both their own xpack.uptime.alerts.actionGroups.tls alert and the example.people-in-space alert with uptime as the consumer.

This does not allow any Uptime user with all privileges to create an example.people-in-space alert. To create an example.people-in-space alert, the Uptime user needs both all in Uptime and in AlertsExample, as we always check whether the user is privileged to execute an operation (create/enable/delete etc.) in both the alert’s consumer and its producer.

The one exception to this is when the producer is alerts, which represents a built-in AlertType, in which case we only check for consumer privileges as all users are privileged to create built-in types by definition.

via #67157

The EventLog Setup contract now exposes a registerSavedObjectProvider method which can be used to register a Saved Object provider.

export interface IEventLogService {
   isEnabled(): boolean;
   isLoggingEntries(): boolean;
   isIndexingEntries(): boolean;
   registerProviderActions(provider: string, actions: string[]): void;
   isProviderActionRegistered(provider: string, action: string): boolean;
   getProviderActions(): Map<string, Set<string>>;
   registerSavedObjectProvider(type: string, provider: SavedObjectProvider): void;
   getLogger(properties: IEvent): IEventLogger;
 }

This API specifies the Saved Object type and a "provider" callback that is called whenever a new request asks for that type of Saved Object.

This example shows a provider for the alert SavedObject type, which creates a new AlertsClient for the request and returns a getter that attempts to get the SavedObject by its id.

via #73257

eventLogService.registerSavedObjectProvider('alert', (request: KibanaRequest) => {
    const client = getAlertsClientWithRequest(request);
    return (type: string, id: string) => client.get({ id });
});

The EventLog maintains a registry of each provider, and creates a getter on demand when the user actually requests an object of a certain type. An AlertsClient is only instantiated if the user requests to the events reference an Alert. Once a getter is created for a specific request, it is cached for the remainder of the lifecycle of that request. This means a single provider is used for multiple gets made by the request.

The SO service was refactored to use elasticsearch-js under the hood. This change might affect plugins reading the response status field from the SO error bubbled to the Solutions code because the Elasticsearch error no longer provides the status field (statusCode is still provided).

Several plugins were adjusted to check SO errors with SavedObjectsErrorHelpers. Plugins must use this because we are going to stop wrapping errors in the Boom object.

via #72289

If you want your plugin to grant a user access to Alerts Management, you must specify it under Management in your feature configuration:

management: {
    insightsAndAlerting: ['triggersActions'],
},

You can specify it in three places:

You’re likely to have to specify this in 3 places in your plugin to cover all 3 scenarios. Although this is more verbose than before, it aligns with the rest of Kibana. It also means that the Triggers and Actions plugin no longer needs to know about each plugin that wants to gain access (which means Kibana can more easily support future alerting usage).

via #72029

casesConfiguration was renamed to incidentConfiguration. Added optional attributeisCaseOwned.

via #73778

casesConfiguration was renamed to incidentConfiguration. Added optional attributeisCaseOwned.

via #74357

via #77327