Merging in master

.eslintrc.js

@@ -1316,7 +1316,7 @@ module.exports = {
 
     {
       files: [
-        // platform-team owned code
+        // core-team owned code
         'src/core/**',
         'x-pack/plugins/features/**',
         'x-pack/plugins/licensing/**',
@@ -1325,6 +1325,14 @@ module.exports = {
         'packages/kbn-config-schema',
         'src/plugins/status_page/**',
         'src/plugins/saved_objects_management/**',
+        'packages/kbn-analytics/**',
+        'packages/kbn-telemetry-tools/**',
+        'src/plugins/kibana_usage_collection/**',
+        'src/plugins/usage_collection/**',
+        'src/plugins/telemetry/**',
+        'src/plugins/telemetry_collection_manager/**',
+        'src/plugins/telemetry_management_section/**',
+        'x-pack/plugins/telemetry_collection_xpack/**',
       ],
       rules: {
         '@typescript-eslint/prefer-ts-expect-error': 'error',

docs/developer/plugin-list.asciidoc

@@ -224,7 +224,7 @@ which also contains the timelion APIs and backend, look at the vis_type_timelion
 |This plugins contains helpers to redirect legacy URLs. It can be used to forward old URLs to their new counterparts.
 
 
-|{kib-repo}blob/{branch}/src/plugins/usage_collection/README.md[usageCollection]
+|{kib-repo}blob/{branch}/src/plugins/usage_collection/README.mdx[usageCollection]
 |The Usage Collection Service defines a set of APIs for other plugins to report the usage of their features. At the same time, it provides necessary the APIs for other services (i.e.: telemetry, monitoring, ...) to consume that usage data.
 
 

docs/settings/alert-action-settings.asciidoc

@@ -40,6 +40,8 @@ You can configure the following settings in the `kibana.yml` file.
 
 [cols="2*<"]
 |===
+| `xpack.actions.enabled`
+  | Feature toggle that enables Actions in {kib}. Defaults to `true`.
 
 | `xpack.actions.allowedHosts` {ess-icon}
   | A list of hostnames that {kib} is allowed to connect to when built-in actions are triggered. It defaults to `[*]`, allowing any host, but keep in mind the potential for SSRF attacks when hosts are not explicitly added to the allowed hosts. An empty list `[]` can be used to block built-in actions from making any external connections. +
@@ -51,6 +53,24 @@ You can configure the following settings in the `kibana.yml` file.
   +
   Disabled action types will not appear as an option when creating new connectors, but existing connectors and actions of that type will remain in {kib} and will not function.
 
+| `xpack.actions.preconfigured`
+  | Specifies preconfigured action IDs and configs. Defaults to {}.
+
+| `xpack.actions.proxyUrl` {ess-icon}
+  | Specifies the proxy URL to use, if using a proxy for actions. By default, no proxy is used.
+
+| `xpack.actions.proxyHeaders` {ess-icon}
+  | Specifies HTTP headers for the proxy, if using a proxy for actions. Defaults to {}.
+
+a|`xpack.actions.`
+`proxyRejectUnauthorizedCertificates` {ess-icon}
+  | Set to `false` to bypass certificate validation for the proxy, if using a proxy for actions. Defaults to `true`.
+
+| `xpack.actions.rejectUnauthorized` {ess-icon}
+  | Set to `false` to bypass certificate validation for actions. Defaults to `true`. +
+  +
+  As an alternative to setting both `xpack.actions.proxyRejectUnauthorizedCertificates` and `xpack.actions.rejectUnauthorized`, you can point the OS level environment variable `NODE_EXTRA_CA_CERTS` to a file that contains the root CAs needed to trust certificates.
+
 |===
 
 [float]

docs/user/alerting/action-types/pre-configured-connectors.asciidoc

@@ -95,7 +95,7 @@ This example shows a preconfigured action type with one out-of-the box connector
       name: 'Server log #xyz'
 ```
 
-<1> `enabledActionTypes` excludes the preconfigured action type to prevent creating and deleting connectors.
+<1> `enabledActionTypes` prevents the preconfigured action type from creating and deleting connectors. For more details, check <<action-settings, Action settings>>.
 <2> `preconfigured` is the setting for defining the list of available connectors for the preconfigured action type.
 
 [[managing-pre-configured-action-types]]

docs/user/alerting/alert-types.asciidoc

@@ -27,7 +27,7 @@ For domain-specific alerts, refer to the documentation for that app.
 * {observability-guide}/create-alerts.html[Observability alerts]
 * {security-guide}/prebuilt-rules.html[Security alerts]
 * <<geo-alerting, Maps alerts>>
-* <<xpack-ml, ML alerts>>
+* {ml-docs}/ml-configuring-alerts.html[{ml-cap} alerts]
 
 [NOTE]
 ==============================================

docs/user/alerting/alerting-getting-started.asciidoc

@@ -5,7 +5,7 @@
 
 --
 
-Alerting allows you to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and <<xpack-ml,*ML*>>, can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, actions>> and <<alert-types, alerts>> (known as stack alerts) for you to use.
+Alerting allows you to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, actions>> and <<alert-types, alerts>> (known as stack alerts) for you to use.
 
 image::images/alerting-overview.png[Alerts and actions UI]
 
@@ -157,7 +157,7 @@ Pre-packaged *alert types* simplify setup, hide the details complex domain-speci
 
 If you are using an *on-premises* Elastic Stack deployment:
 
-* In the kibana.yml configuration file, add the <<alert-action-settings-kb,`xpack.encryptedSavedObjects.encryptionKey`>> setting.
+* In the kibana.yml configuration file, add the <<general-alert-action-settings,`xpack.encryptedSavedObjects.encryptionKey`>> setting.
 * For emails to have a footer with a link back to {kib}, set the <<server-publicBaseUrl, `server.publicBaseUrl`>> configuration setting.
 
 If you are using an *on-premises* Elastic Stack deployment with <<using-kibana-with-security, *security*>>:

docs/user/alerting/alerting-production-considerations.asciidoc

@@ -2,17 +2,17 @@
 [[alerting-production-considerations]]
 == Production considerations
 
-{kib} alerting run both alert checks and actions as persistent background tasks managed by the Kibana Task Manager. This has two major benefits:
+{kib} alerting runs both alert checks and actions as persistent background tasks managed by the Kibana Task Manager. This has two major benefits:
 
-* *Persistence*: all task state and scheduling is stored in {es}, so if {kib} is restarted, alerts and actions will pick up where they left off.  Task definitions for alerts and actions are stored in the index specified by `xpack.task_manager.index` (defaults to `.kibana_task_manager`).  It is important to have at least 1 replica of this index for production deployments, since if you lose this index all scheduled alerts and actions are also lost.
+* *Persistence*: all task state and scheduling is stored in {es}, so if you restart {kib}, alerts and actions will pick up where they left off.  Task definitions for alerts and actions are stored in the index specified by <<task-manager-settings, `xpack.task_manager.index`>>.  The default is `.kibana_task_manager`.  You must have at least one replica of this index for production deployments.  If you lose this index, all scheduled alerts and actions are lost.
 * *Scaling*: multiple {kib} instances can read from and update the same task queue in {es}, allowing the alerting and action load to be distributed across instances. In cases where a {kib} instance no longer has capacity to run alert checks or actions, capacity can be increased by adding additional {kib} instances.
 
 [float]
 === Running background alert checks and actions
 
 {kib} background tasks are managed by:
 
-* Polling an {es} task index for overdue tasks at 3 second intervals.  This interval can be changed using the `xpack.task_manager.poll_interval` setting.
+* Polling an {es} task index for overdue tasks at 3 second intervals.  You can change this interval using the <<task-manager-settings, `xpack.task_manager.poll_interval`>> setting.
 * Tasks are then claiming them by updating them in the {es} index, using optimistic concurrency control to prevent conflicts. Each {kib} instance can run a maximum of 10 concurrent tasks, so a maximum of 10 tasks are claimed each interval. 
 * Tasks are run on the {kib} server. 
 * In the case of alerts which are recurring background checks, upon completion the task is scheduled again according to the <<defining-alerts-general-details, check interval>>.
@@ -32,4 +32,4 @@ For details on the settings that can influence the performance and throughput of
 [float]
 === Deployment considerations
 
-{es} and {kib} instances use the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as http://www.ntp.org/[Network Time Protocol].
+{es} and {kib} instances use the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as http://www.ntp.org/[Network Time Protocol].

docs/user/alerting/defining-alerts.asciidoc

@@ -2,7 +2,7 @@
 [[defining-alerts]]
 == Defining alerts
 
-{kib} alerts can be created in a variety of apps including <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, <<uptime-app,*Uptime*>> and from <<management,*Management*>> UI. While alerting details may differ from app to app, they share a common interface for defining and configuring alerts that this section describes in more detail.
+{kib} alerts can be created in a variety of apps including <<xpack-apm,*APM*>>, <<xpack-ml,*{ml-app}*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, <<uptime-app,*Uptime*>> and from <<management,*Management*>> UI. While alerting details may differ from app to app, they share a common interface for defining and configuring alerts that this section describes in more detail.
 
 [float]
 === Create an alert
@@ -102,29 +102,9 @@ image::images/alert-flyout-add-action.png[You can add multiple actions on an ale
 
 [NOTE]
 ==============================================
-Actions are not required on alerts. In some cases you may want to run an alert without actions first to understand its behavior, and configure actions later.
+Actions are not required on alerts. You can run an alert without actions to understand its behavior, and then <<action-settings, configure actions>> later.
 ==============================================
 
-[float]
-[[actions-configuration]]
-=== Global actions configuration
-Some actions configuration options apply to all actions.
-If you are using an *on-prem* Elastic Stack deployment, you can set these in the kibana.yml file.
-If you are using a cloud deployment, you can set these via the console.
-
-Here's a list of the available global configuration options and an explanation of what each one does:
-
-* `xpack.actions.enabled`: Feature toggle that enables Actions in {kib}. Default: `true`
-* `xpack.actions.allowedHosts`: Specifies an array of host names which actions such as email, Slack, PagerDuty, and webhook can connect to. An element of * indicates any host can be connected to. An empty array indicates no hosts can be connected to. Default: [ {asterisk} ]
-* `xpack.actions.enabledActionTypes`: Specifies an array of action types that are enabled. An {asterisk} indicates all action types registered are enabled. The action types that {kib} provides are `.email`, `.index`, `.jira`, `.pagerduty`, `.resilient`, `.server-log`, `.servicenow`, `.servicenow-sir`, `.slack`,   `.teams`, and `.webhook`. Default: [ {asterisk} ]
-* `xpack.actions.preconfigured`: Specifies preconfigured action IDs and configs. Default: {}
-* `xpack.actions.proxyUrl`: Specifies the proxy URL to use, if using a proxy for actions.
-* `xpack.actions.proxyHeader`: Specifies HTTP headers for proxy, if using a proxy for actions.
-* `xpack.actions.proxyRejectUnauthorizedCertificates`: Set to `false` to bypass certificate validation for proxy, if using a proxy for actions.
-* `xpack.actions.rejectUnauthorized`: Set to `false` to bypass certificate validation for actions.
-
-*NOTE:* As an alternative to both `xpack.actions.proxyRejectUnauthorizedCertificates` and `xpack.actions.rejectUnauthorized`, the OS level environment variable `NODE_EXTRA_CA_CERTS` can be set to point to a file that contains the root CA(s) needed for certificates to be trusted. 
-
 [float]
 === Manage alerts
 

src/core/CONVENTIONS.md

@@ -285,7 +285,7 @@ export class Plugin {
 
 #### Usage Collection
 
-For creating and registering a Usage Collector. Collectors should be defined in a separate directory `server/collectors/`. You can read more about usage collectors on `src/plugins/usage_collection/README.md`.
+For creating and registering a Usage Collector. Collectors should be defined in a separate directory `server/collectors/`. You can read more about usage collectors on `src/plugins/usage_collection/README.mdx`.
 
 ```ts
 // server/collectors/register.ts

src/core/server/saved_objects/service/lib/repository.ts

@@ -1640,7 +1640,7 @@ export class SavedObjectsRepository {
    *
    * When using incrementCounter for collecting usage data, you need to ensure
    * that usage collection happens on a best-effort basis and doesn't
-   * negatively affect your plugin or users. See https://github.com/elastic/kibana/blob/master/src/plugins/usage_collection/README.md#tracking-interactions-with-incrementcounter)
+   * negatively affect your plugin or users. See https://github.com/elastic/kibana/blob/master/src/plugins/usage_collection/README.mdx#tracking-interactions-with-incrementcounter)
    *
    * @example
    * ```ts

src/plugins/discover/public/application/components/create_discover_grid_directive.tsx

@@ -6,19 +6,27 @@
  * Side Public License, v 1.
  */
 
-import * as React from 'react';
+import React, { useState } from 'react';
 import { I18nProvider } from '@kbn/i18n/react';
 import { DiscoverGrid, DiscoverGridProps } from './discover_grid/discover_grid';
 import { getServices } from '../../kibana_services';
+import { ElasticSearchHit } from '../doc_views/doc_views_types';
 
 export const DataGridMemoized = React.memo((props: DiscoverGridProps) => (
   <DiscoverGrid {...props} />
 ));
 
 export function DiscoverGridEmbeddable(props: DiscoverGridProps) {
+  const [expandedDoc, setExpandedDoc] = useState<ElasticSearchHit | undefined>(undefined);
+
   return (
     <I18nProvider>
-      <DataGridMemoized {...props} services={getServices()} />
+      <DataGridMemoized
+        {...props}
+        setExpandedDoc={setExpandedDoc}
+        expandedDoc={expandedDoc}
+        services={getServices()}
+      />
     </I18nProvider>
   );
 }

src/plugins/kibana_usage_collection/server/collectors/kibana/get_saved_object_counts.test.ts

@@ -12,7 +12,7 @@ import { getSavedObjectsCounts } from './get_saved_object_counts';
 export function mockGetSavedObjectsCounts(params: any) {
   const esClient = elasticsearchServiceMock.createClusterClient().asInternalUser;
   esClient.search.mockResolvedValue(
-    // @ts-ignore we only care about the response body
+    // @ts-expect-error we only care about the response body
     {
       body: { ...params },
     }

src/plugins/maps_legacy/common/ems_defaults.ts

@@ -9,6 +9,6 @@
 // Default config for the elastic hosted EMS endpoints
 export const DEFAULT_EMS_FILE_API_URL = 'https://vector.maps.elastic.co';
 export const DEFAULT_EMS_TILE_API_URL = 'https://tiles.maps.elastic.co';
-export const DEFAULT_EMS_LANDING_PAGE_URL = 'https://maps.elastic.co/v7.11';
+export const DEFAULT_EMS_LANDING_PAGE_URL = 'https://maps.elastic.co/v7.12';
 export const DEFAULT_EMS_FONT_LIBRARY_URL =
   'https://tiles.maps.elastic.co/fonts/{fontstack}/{range}.pbf';

src/plugins/telemetry/README.md

@@ -6,7 +6,7 @@ Telemetry allows Kibana features to have usage tracked in the wild. The general
 2. Sending a payload of usage data up to Elastic's telemetry cluster.
 3. Viewing usage data in the Kibana instance of the telemetry cluster (Viewing).
 
-This plugin is responsible for sending usage data to the telemetry cluster. For collecting usage data, use the [`usageCollection` plugin](../usage_collection/README.md)
+This plugin is responsible for sending usage data to the telemetry cluster. For collecting usage data, use the [`usageCollection` plugin](../usage_collection/README.mdx)
 
 ## Telemetry Plugin public API
 

src/plugins/telemetry/public/services/telemetry_sender.test.ts

@@ -126,9 +126,7 @@ describe('TelemetrySender', () => {
         originalFetch = window.fetch;
       });
 
-      // @ts-ignore
       beforeEach(() => (window.fetch = mockFetch = jest.fn()));
-      // @ts-ignore
       afterAll(() => (window.fetch = originalFetch));
 
       it('does not send if already sending', async () => {
@@ -250,9 +248,7 @@ describe('TelemetrySender', () => {
       originalSetInterval = window.setInterval;
     });
 
-    // @ts-ignore
     beforeEach(() => (window.setInterval = mockSetInterval = jest.fn()));
-    // @ts-ignore
     afterAll(() => (window.setInterval = originalSetInterval));
 
     it('calls sendIfDue every 60000 ms', () => {

src/plugins/telemetry/public/services/telemetry_service.test.ts

@@ -211,9 +211,7 @@ describe('TelemetryService', () => {
       originalFetch = window.fetch;
     });
 
-    // @ts-ignore
     beforeEach(() => (window.fetch = mockFetch = jest.fn()));
-    // @ts-ignore
     afterAll(() => (window.fetch = originalFetch));
 
     it('reports opt-in status to telemetry url', async () => {

src/plugins/telemetry/server/fetcher.ts

@@ -8,7 +8,6 @@
 
 import { Observable, Subscription, timer } from 'rxjs';
 import { take } from 'rxjs/operators';
-// @ts-ignore
 import fetch from 'node-fetch';
 import {
   TelemetryCollectionManagerPluginStart,

src/plugins/telemetry/server/routes/telemetry_opt_in_stats.test.ts

@@ -7,7 +7,6 @@
  */
 
 jest.mock('node-fetch');
-// @ts-ignore
 import fetch from 'node-fetch';
 import { sendTelemetryOptInStatus } from './telemetry_opt_in_stats';
 import { StatsGetterConfig } from 'src/plugins/telemetry_collection_manager/server';

src/plugins/telemetry/server/telemetry_collection/get_cluster_info.test.ts

@@ -11,14 +11,12 @@ import { getClusterInfo } from './get_cluster_info';
 
 export function mockGetClusterInfo(clusterInfo: any) {
   const esClient = elasticsearchServiceMock.createClusterClient().asInternalUser;
-  esClient.info
-    // @ts-ignore we only care about the response body
-    .mockResolvedValue(
-      // @ts-ignore we only care about the response body
-      {
-        body: { ...clusterInfo },
-      }
-    );
+  esClient.info.mockResolvedValue(
+    // @ts-expect-error we only care about the response body
+    {
+      body: { ...clusterInfo },
+    }
+  );
   return esClient;
 }
 

src/plugins/telemetry/server/telemetry_collection/get_cluster_stats.test.ts

@@ -21,7 +21,7 @@ describe('get_cluster_stats', () => {
     const response = Promise.resolve({ body: { cluster_uuid: '1234' } });
     const esClient = elasticsearchServiceMock.createClusterClient().asInternalUser;
     esClient.cluster.stats.mockImplementationOnce(
-      // @ts-ignore the method only cares about the response body
+      // @ts-expect-error the method only cares about the response body
       async (_params = { timeout: TIMEOUT }) => {
         return response;
       }

src/plugins/telemetry/server/telemetry_collection/get_data_telemetry/get_data_telemetry.test.ts

@@ -265,7 +265,7 @@ function mockEsClient(
   indexStats: any = {}
 ) {
   const esClient = elasticsearchServiceMock.createClusterClient().asInternalUser;
-  // @ts-ignore
+  // @ts-expect-error
   esClient.indices.getMapping.mockImplementationOnce(async () => {
     const body = Object.fromEntries(
       indicesMappings.map((index) => [
@@ -294,7 +294,7 @@ function mockEsClient(
     );
     return { body };
   });
-  // @ts-ignore
+  // @ts-expect-error
   esClient.indices.stats.mockImplementationOnce(async () => {
     return { body: indexStats };
   });