Merge branch 'master' into tsvb-legend-color-picker

Author: kibanamachine

.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',

.github/CODEOWNERS

@@ -240,6 +240,7 @@ x-pack/plugins/telemetry_collection_xpack/schema/ @elastic/kibana-core @elastic/
 # Security
 /src/core/server/csp/  @elastic/kibana-security @elastic/kibana-core
 /src/plugins/security_oss/ @elastic/kibana-security
+/src/plugins/spaces_oss/ @elastic/kibana-security
 /test/security_functional/ @elastic/kibana-security
 /x-pack/plugins/spaces/  @elastic/kibana-security
 /x-pack/plugins/encrypted_saved_objects/  @elastic/kibana-security

dev_docs/building_blocks.mdx

@@ -0,0 +1,138 @@
+---
+id: kibBuildingBlocks
+slug: /kibana-dev-docs/building-blocks
+title: Building blocks
+summary: Consider these building blocks when developing your plugin.
+date: 2021-02-24
+tags: ['kibana','onboarding', 'dev', 'architecture']
+---
+
+When building a plugin in Kibana, there are a handful of architectural "building blocks" you can use. Some of these building blocks are "higher-level", 
+and some are "lower-level". High-level building blocks come 
+with many built-in capabilities, require less maintenance, and evolve new feature sets over time with little to no
+ impact on consumers. When developers use high-level building blocks, new features are exposed consistently, across all of Kibana, at the same time.
+  On the downside, they are not as flexible as our low-level building blocks. 
+ 
+ Low-level building blocks
+ provide greater flexibility, but require more code to stitch them together into a meaningful UX. This results in higher maintenance cost for consumers and greater UI/UX variability
+ across Kibana.
+
+ For example, if an application is using <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/> and 
+ <DocLink id="kibBuildingBlocks" section="search-source" text="Search Source"/>, 
+ their application would automatically support runtime fields. If the app is instead using the
+ lower-level <DocLink id="kibBuildingBlocks" section="search-strategy" text="Search Strategy"/>, additional work would be required.
+
+Armed with this knowledge, you can choose what works best for your use case!
+
+# Application building blocks
+
+## UI components
+
+The following high-level building blocks can be rendered directly into your application UI.
+
+### Query Bar
+
+The <DocLink id="kibDataPlugin" text="Data plugin"/> provides a high-level Query Bar component that comes with support for Lucene, KQL, Saved Queries, 
+and <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>.
+
+If you would like to expose the ability to search and filter on Elasticsearch data, the Query Bar provided by the
+<DocLink id="kibDataPlugin" text="Data plugin"/> 
+ is your go-to building block.
+
+**Github labels**: `Team:AppServices`, `Feature:QueryBar`
+
+### Dashboard Embeddable
+
+Add a Dashboard Embeddable directly inside your application to provide users with a set of visualizations and graphs that work seamlessly
+with the <DocLink id="kibBuildingBlocks" section="query-bar" text="Query Bar"/>. Every feature that is added to a registered 
+<DocLink id="kibBuildingBlocks" section="embeddables" text="Embeddable"/> 
+(Lens, Maps, Saved Searches and more) will be available automatically, as well as any
+ <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions"/> that are
+ added to the Embeddable context menu panel (for example, drilldowns, custom panel time ranges, and "share to" features).
+
+The Dashboard Embeddable is one of the highest-level UI components you can add to your application.
+
+**Github labels**: `Team:Presentation`, `Feature:Dashboard`
+
+### Lens Embeddable
+
+Check out the Lens Embeddable if you wish to show users visualizations based on Elasticsearch data without worrying about query building and chart rendering. It's built on top of the
+ <DocLink id="kibBuildingBlocks" section="expressions" text="Expression language"/>, and integrates with
+  <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>
+ and <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions"/>. Using the same configuration, it's also possible to link to
+ a prefilled Lens editor, allowing the user to drill deeper and explore their data.
+
+**Github labels**: `Team:KibanaApp`, `Feature:Lens`
+
+### Map Embeddable
+
+Check out the Map Embeddable if you wish to embed a map in your application.
+
+**Github labels**: `Team:Geo`
+
+## Searching
+
+### Index Patterns
+
+<DocLink id="kibDataPlugin" section="index-patterns-api" text="Index Patterns"/> are a high-level, space-aware abstraction layer that sits 
+above Data Streams and Elasticsearch indices. Index Patterns provide users the 
+ability to define and customize the data they wish to search and filter on, on a per-space basis. For example, users can specify a set of indices, 
+and they can customize the field list with runtime fields, formatting options and custom labels.
+
+Index Patterns are used in many other high-level building blocks so we highly recommend you consider this building block for your search needs.
+
+**Github labels**: `Team:AppServices`, `Feature:Index Patterns`
+
+### Search Source
+
+<DocLink id="kibDataPlugin" section="searchsource" text="Search Source"/> is a high-level search service offered by the
+<DocLink id="kibDataPlugin" section="searchsource" text="Data plugin"/>. It requires an
+<DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Pattern"/>, and abstracts away the raw ES DSL and search endpoint. Internally
+it uses the ES <DocLink id="kibBuildingBlocks" section="search-strategies" text="Search Strategy"/>. Use Search Source if you need to query data 
+from Elasticsearch, and you aren't already using one of the high-level UI Components that handles this internally.
+
+**Github labels**: `Team:AppServices`, `Feature:Search`
+
+### Search Strategies
+
+Search Strategies are a low-level building block that abstracts away search details, like what REST endpoint is being called. The ES Search Strategy 
+is a very lightweight abstraction layer that sits just above querying ES with the elasticsearch-js client. Other search stragies are offered for other 
+languages, like EQL and SQL. These are very low-level building blocks so expect a lot of glue work to make these work with the higher-level abstractions.
+
+**Github labels**: `Team:AppServices`, `Feature:Search`
+
+### Expressions
+
+Expressions are a low-level building block that can be used if you have advanced search needs that requiring piping results into additional functionality, like
+joining and manipulating data. Lens and Canvas are built on top of Expressions. Most developers should be able to use
+ <DocLink id="kibBuildingBlocks" section="lens-embeddable" text="Lens"/> or
+  <DocLink id="kibBuildingBlocks" section="search-source" text="Search Source"/>, rather than need to access the Expression language directly.  
+
+**Github labels**: `Team:AppServices`, `Feature:ExpressionLanguage`
+
+## Saved Objects
+
+<DocLink id="kibDevDocsSavedObjectsIntro" text="Saved Objects" /> should be used if you need to persist application-level information. If you were building a TODO
+application, each TODO item would be a `Saved Object`. Saved objects come pre-wired with support for bulk export/import, security features like space sharing and
+space isolation, and tags.
+
+**Github labels**: `Team:Core`, `Feature:Saved Objects`
+
+# Integration building blocks
+
+Use the following building blocks to create an inter-connected, cross-application, holistic Kibana experience. These building blocks allow you to expose functionality
+ that promotes your own application into other applications, as well as help developers of other applications integrate into your app.
+
+## UI Actions & Triggers
+
+Integrate custom actions into other applications by registering UI Actions attached to existing triggers. For example, the Maps
+application could register a UI Action called "View in Maps" to appear any time the user clicked a geo field to filter on.
+
+**Github labels**: `Team:AppServices`, `Feature:UIActions`
+
+## Embeddables
+
+Embeddables help you integrate your application with the Dashboard application. Register your custom UI Widget as an Embeddable and users will
+be able to add it as a panel on a Dashboard. With a little extra work, it can also be exposed in Canvas workpads. 
+
+**Github labels**: `Team:AppServices`, `Feature:Embeddables`

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.
 
 

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/es_ui_shared/__packages_do_not_import__/errors/es_error_parser.ts

@@ -11,14 +11,14 @@ interface ParsedError {
   cause: string[];
 }
 
-const getCause = (obj: any = {}, causes: string[] = []): string[] => {
+export const getEsCause = (obj: any = {}, causes: string[] = []): string[] => {
   const updated = [...causes];
 
   if (obj.caused_by) {
     updated.push(obj.caused_by.reason);
 
     // Recursively find all the "caused by" reasons
-    return getCause(obj.caused_by, updated);
+    return getEsCause(obj.caused_by, updated);
   }
 
   return updated.filter(Boolean);
@@ -27,7 +27,7 @@ const getCause = (obj: any = {}, causes: string[] = []): string[] => {
 export const parseEsError = (err: string): ParsedError => {
   try {
     const { error } = JSON.parse(err);
-    const cause = getCause(error);
+    const cause = getEsCause(error);
     return {
       message: error.reason,
       cause,

src/plugins/es_ui_shared/__packages_do_not_import__/errors/handle_es_error.ts

@@ -9,6 +9,7 @@
 import { ApiError } from '@elastic/elasticsearch';
 import { ResponseError } from '@elastic/elasticsearch/lib/errors';
 import { IKibanaResponse, KibanaResponseFactory } from 'kibana/server';
+import { getEsCause } from './es_error_parser';
 
 interface EsErrorHandlerParams {
   error: ApiError;
@@ -34,7 +35,15 @@ export const handleEsError = ({
     const { statusCode, body } = error as ResponseError;
     return response.customError({
       statusCode,
-      body: { message: body.error?.reason },
+      body: {
+        message: body.error?.reason,
+        attributes: {
+          // The full original ES error object
+          error: body.error,
+          // We assume that this is an ES error object with a nested caused by chain if we can see the "caused_by" field at the top-level
+          causes: body.error?.caused_by ? getEsCause(body.error) : undefined,
+        },
+      },
     });
   }
   // Case: default

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 },
     }