Merge branch 'master' into escape-list-ids

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

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/jira.asciidoc

@@ -65,44 +65,13 @@ API token (or password)::  Jira API authentication token (or password) for HTTP
 
 Jira actions have the following configuration properties:
 
-Subaction::        The subaction to perform: `pushToService`, `getIncident`, `issueTypes`, `fieldsByIssueType`, `issues`, `issue`, or `getFields`.
-Subaction params:: The parameters of the subaction.
-
-==== `pushToService` subaction configuration
-
-Incident:: A Jira incident has the following properties:
-* `summary` - The title of the issue.
-* `description` - A description of the issue.
-* `externalId` - The ID of the issue in Jira. If present, the issue is updated. Otherwise, a new issue is created.
-* `issueType` - The ID of the issue type in Jira.
-* `priority` - The priority level in Jira. Example: `Medium`.
-* `labels` - An array of labels. Labels cannot contain spaces.
-* `parent` - The parent issue ID or key. Only for subtask issue types.
-Comments:: A comment in the form of `{ commentId: string, version: string, comment: string }`.
-
-==== `getIncident` subaction configuration
-
-External ID:: The ID of the issue in Jira.
-
-==== `issueTypes` subaction configuration
-
-The `issueTypes` subaction has no parameters. Provide an empty object `{}`.
-
-==== `fieldsByIssueType` subaction configuration
-
-ID:: The ID of the issue in Jira.
-
-==== `issues` subaction configuration
-
-Title:: The title to search for.
-
-==== `issue` subaction configuration
-
-ID:: The ID of the issue in Jira.
-
-==== `getFields` subaction configuration
-
-The `getFields` subaction has no parameters. Provide an empty object `{}`.
+Issue type:: The type of the issue.
+Priority:: The priority of the incident.
+Labels:: The labels for the incident.
+Title:: A title for the issue, used for searching the contents of the knowledge base.
+Description:: The details about the incident.
+Parent:: The ID or key of the parent issue. Only for `Subtask` issue types.
+Additional comments:: Additional information for the client, such as how to troubleshoot the issue.
 
 [[configuring-jira]]
 ==== Configuring and testing Jira

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/action-types/resilient.asciidoc

@@ -65,30 +65,11 @@ API key secret::  The authentication key secret for HTTP Basic authentication.
 
 IBM Resilient actions have the following configuration properties:
 
-Subaction::        The subaction to perform: `pushToService`, `getFields`, `incidentTypes`, or `severity`.
-Subaction params:: The parameters of the subaction.
-
-==== `pushToService` subaction configuration
-
-Incident:: The IBM resilient incident has the following properties:
-* `name` - A name for the issue, used for searching the contents of the knowledge base.
-* `description` - The details about the incident.
-* `externalId` - The ID of the incident in IBM Resilient. If present, the incident is updated. Otherwise, a new incident is created.
-* `incidentTypes` - An array with the IDs of IBM Resilient incident types.
-* `severityCode` - The IBM Resilient ID of the severity code.
-Comments:: A comment in the form of `{ commentId: string, version: string, comment: string }`.
-
-===== `getFields` subaction configuration
-
-The `getFields` subaction has not parameters. Provide an empty object `{}`.
-
-===== `incidentTypes` subaction configuration
-
-The `incidentTypes` subaction has no parameters. Provide an empty object `{}`.
-
-===== `severity` subaction configuration
-
-The `severity` subaction has no parameters. Provide an empty object `{}`.
+Incident types:: The type of the incident.
+Severity code:: The severity of the incident.
+Name:: A name for the issue, used for searching the contents of the knowledge base.
+Description:: The details about the incident.
+Additional comments:: Additional information for the client, such as how to troubleshoot the issue.
 
 [[configuring-resilient]]
 ==== Configuring and testing IBM Resilient

docs/user/alerting/action-types/servicenow.asciidoc

@@ -60,33 +60,12 @@ Password::  Password for HTTP Basic authentication.
 
 ServiceNow actions have the following configuration properties:
 
-Subaction::        The subaction to perform: `pushToService`, `getFields`, `getIncident`, or `getChoices`.
-Subaction params:: The parameters of the subaction.
-
-==== `pushToService` subaction configuration
-
-Incident:: The ServiceNow incident has the following properties:
-* `short_description` - A short description for the incident, used for searching the contents of the knowledge base.
-* `description` - The details about the incident.
-* `externalId` - The ID of the incident in ServiceNow. If present, the incident is updated. Otherwise, a new incident is created.
-* `severity` - The severity of the incident.
-* `urgency` - The extent to which the incident resolution can delay.
-* `impact` - The effect an incident has on business. Can be measured by the number of affected users or by how critical it is to the business in question.
-* `category` - The name of the category in ServiceNow.
-* `subcategory` - The name of the subcategory in ServiceNow.
-Comments:: A comment in the form of `{ commentId: string, version: string, comment: string }`.
-
-===== `getFields` subaction configuration
-
-The `getFields` subaction has no parameters. Provide an empty object `{}`.
-
-===== `getIncident` subaction configuration
-
-External ID:: The ID of the incident in ServiceNow.
-
-===== `getChoices` subaction configuration
-
-Fields:: An array of fields. Example: `[priority, category, impact]`.
+Urgency::              The extent to which the incident resolution can delay.
+Severity::             The severity of the incident.
+Impact::               The effect an incident has on business. Can be measured by the number of affected users or by how critical it is to the business in question.
+Short description::    A short description for the incident, used for searching the contents of the knowledge base.
+Description::          The details about the incident.
+Additional comments::  Additional information for the client, such as how to troubleshoot the issue.
 
 [[configuring-servicenow]]
 ==== Configuring and testing ServiceNow

docs/user/alerting/alert-types.asciidoc

@@ -28,7 +28,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]
 ==============================================