Merge branch 'master' into fix/payload-bytes

Author: kibanamachine

.github/CODEOWNERS

@@ -251,6 +251,7 @@ x-pack/plugins/telemetry_collection_xpack/schema/ @elastic/kibana-core @elastic/
 /x-pack/test/security_api_integration/ @elastic/kibana-security
 /x-pack/test/security_functional/ @elastic/kibana-security
 /x-pack/test/spaces_api_integration/ @elastic/kibana-security
+/x-pack/test/saved_object_api_integration/ @elastic/kibana-security
 #CC# /x-pack/plugins/security/ @elastic/kibana-security
 
 # Kibana Alerting Services

dev_docs/kibana_platform_plugin_intro.mdx

@@ -7,25 +7,25 @@ date: 2021-01-06
 tags: ['kibana','onboarding', 'dev', 'architecture']
 ---
 
-From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way 
+From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way
 to visualize and analyze data.
 
 From a developer perspective, Kibana is a platform that provides a set of tools to build not only the UI you see in Kibana today, but
-a wide variety of applications that can be used to explore, visualize, and act upon data in Elasticsearch. The platform provides developers the ability 
-to build applications, or inject extra functionality into 
+a wide variety of applications that can be used to explore, visualize, and act upon data in Elasticsearch. The platform provides developers the ability
+to build applications, or inject extra functionality into
 already existing applications. Did you know that almost everything you see in the
 Kibana UI is built inside a plugin? If you removed all plugins from Kibana, you'd be left with an empty navigation menu, and a set of
 developer tools. The Kibana platform is a blank canvas, just waiting for a developer to come along and create something!
 
 ![Kibana personas](assets/kibana_platform_plugin_end_user.png)
- 
+
 ## Platform services
 
 Plugins have access to three kinds of public services:
 
  - Platform services provided by `core` (<DocLink id="kibPlatformIntro" section="core-services" text="Core services"/>)
  - Platform services provided by plugins (<DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>)
- - Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils"). 
+ - Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
 
  The first two items are what make up "Platform services".
 
@@ -37,9 +37,9 @@ clear, and we haven't done a great job of sticking to it. For example, notificat
 Today it looks something like this.
 
 ![Core vs platform plugins vs plugins](assets/platform_plugins_core.png)
- 
+
 <DocAccordion buttonContent="A bit of history">
-When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental 
+When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental
 code needed to build plugins inside core.
 
 In reality, we ended up with many platform-like services living outside of core, with no (short term) intention of moving them. We highly encourage plugin developers to use
@@ -54,7 +54,7 @@ In reality, our plugin model ended up being used like micro-services. Plugins ar
  they desire, without the need to build a plugin.
 
 Another side effect of having many small plugins is that common code often ends up extracted into another plugin. Use case specific utilities are exported,
- that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of 
+ that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
  every publically exposed service", but in today's world, that wouldn't be a very accurate picture.
 
 We recognize the need to better clarify the relationship between core functionality, platform-like plugin functionality, and functionality exposed by other plugins.
@@ -69,19 +69,19 @@ We will continue to focus on adding clarity around these types of services and w
 ### Core services
 
 Sometimes referred to just as Core, Core services provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
-routing, application registration, and notifications. The Core platform is not a plugin itself, although
+routing, application registration, notifications and <DocLink id="kibCoreLogging" text="logging"/>. The Core platform is not a plugin itself, although
 there are some plugins that provide platform functionality. We call these <DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>.
 
 ### Platform plugins
 
-Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the 
+Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
 <DocLink id="kibDataPlugin" text="data"/> plugin. There is no official way to tell if a plugin is a platform plugin or not.
 Platform plugins are _usually_ plugins that are managed by the Platform Group, but we are starting to see some exceptions.
 
 ## Plugins
 
-Plugins are code that is written to extend and customize Kibana. Plugin's don't have to be part of the Kibana repo, though the Kibana 
-repo does contain many plugins! Plugins add customizations by 
+Plugins are code that is written to extend and customize Kibana. Plugin's don't have to be part of the Kibana repo, though the Kibana
+repo does contain many plugins! Plugins add customizations by
 using <DocLink id="kibPlatformIntro" section="extension-points" text="extension points"/> provided by <DocLink id="kibPlatformIntro" section="platform-services" text="platform services"/>.
 Sometimes people confuse the term "plugin" and "application". While often there is a 1:1 relationship between a plugin and an application, it is not always the case.
 A plugin may register many applications, or none.
@@ -97,7 +97,7 @@ adding it to core's application <DocLink id="kibPlatformIntro" section="registry
 
 ### Public plugin API
 
-A plugin's public API consists of everything exported from a plugin's <DocLink id="kibPlatformIntro" section="plugin-lifecycle" text="start or setup lifecycle methods"/>, 
+A plugin's public API consists of everything exported from a plugin's <DocLink id="kibPlatformIntro" section="plugin-lifecycle" text="start or setup lifecycle methods"/>,
 as well as from the top level `index.ts` files that exist in the three "scope" folders:
 
 - common/index.ts
@@ -113,18 +113,18 @@ Core, and plugins, expose different features at different parts of their lifecyc
  specifically-named functions on the service definition.
 
 Kibana has three lifecycles: setup, start, and stop. Each plugin’s setup function is called sequentially while Kibana is setting up
- on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins. 
+ on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
  The stop functions are called sequentially while Kibana is gracefully shutting down the server or when the browser tab or window is being closed.
 
 The table below explains how each lifecycle relates to the state of Kibana.
 
 | lifecycle	| purpose |	server |	browser |
 | ---------- | ------ | ------- | ----- |
 | setup | perform "registration" work to setup environment for runtime |configure REST API endpoint, register saved object types, etc. | configure application routes in SPA, register custom UI elements in extension points, etc. |
-| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.| 
+| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.|
 | stop | cleanup runtime | dispose of active handles before the server shutdown. | store session data in the LocalStorage when the user navigates away from Kibana, etc. |
 
-Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types 
+Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types
 of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.
 
 ## Extension points
@@ -141,4 +141,4 @@ plugins to customize the Kibana experience. Examples of extension points are:
 
 ## Follow up material
 
-Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />
+Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />

docs/api/alerts/find.asciidoc

@@ -49,6 +49,8 @@ Retrieve a paginated set of alerts based on condition.
 NOTE: As alerts change in {kib}, the results on each page of the response also
 change. Use the find API for traditional paginated results, but avoid using it to export large amounts of data.
 
+NOTE: Alert `params` are stored as {ref}/flattened.html[flattened] and analyzed as `keyword`.
+
 [[alerts-api-find-request-codes]]
 ==== Response code
 

docs/development/core/public/kibana-plugin-core-public.appleavehandler.md

@@ -4,6 +4,11 @@
 
 ## AppLeaveHandler type
 
+> Warning: This API is now obsolete.
+> 
+> [AppMountParameters.onAppLeave](./kibana-plugin-core-public.appmountparameters.onappleave.md) has been deprecated in favor of [ScopedHistory.block](./kibana-plugin-core-public.scopedhistory.block.md)
+> 
+
 A handler that will be executed before leaving the application, either when going to another application or when closing the browser tab or manually changing the url. Should return `confirm` to to prompt a message to the user before leaving the page, or `default` to keep the default behavior (doing nothing).
 
 See [AppMountParameters](./kibana-plugin-core-public.appmountparameters.md) for detailed usage examples.

docs/development/core/public/kibana-plugin-core-public.appmountparameters.onappleave.md

@@ -4,6 +4,11 @@
 
 ## AppMountParameters.onAppLeave property
 
+> Warning: This API is now obsolete.
+> 
+> [ScopedHistory.block](./kibana-plugin-core-public.scopedhistory.block.md) should be used instead.
+> 
+
 A function that can be used to register a handler that will be called when the user is leaving the current application, allowing to prompt a confirmation message before actually changing the page.
 
 This will be called either when the user goes to another application, or when trying to close the tab or manually changing the url.

docs/development/core/public/kibana-plugin-core-public.scopedhistory.block.md

@@ -4,15 +4,10 @@
 
 ## ScopedHistory.block property
 
-Not supported. Use [AppMountParameters.onAppLeave](./kibana-plugin-core-public.appmountparameters.onappleave.md)<!-- -->.
+Add a block prompt requesting user confirmation when navigating away from the current page.
 
 <b>Signature:</b>
 
 ```typescript
 block: (prompt?: string | boolean | History.TransitionPromptHook<HistoryLocationState> | undefined) => UnregisterCallback;
 ```
-
-## Remarks
-
-We prefer that applications use the `onAppLeave` API because it supports a more graceful experience that prefers a modal when possible, falling back to a confirm dialog box in the beforeunload case.
-

docs/development/core/public/kibana-plugin-core-public.scopedhistory.md

@@ -27,7 +27,7 @@ export declare class ScopedHistory<HistoryLocationState = unknown> implements Hi
 |  Property | Modifiers | Type | Description |
 |  --- | --- | --- | --- |
 |  [action](./kibana-plugin-core-public.scopedhistory.action.md) |  | <code>Action</code> | The last action dispatched on the history stack. |
-|  [block](./kibana-plugin-core-public.scopedhistory.block.md) |  | <code>(prompt?: string &#124; boolean &#124; History.TransitionPromptHook&lt;HistoryLocationState&gt; &#124; undefined) =&gt; UnregisterCallback</code> | Not supported. Use [AppMountParameters.onAppLeave](./kibana-plugin-core-public.appmountparameters.onappleave.md)<!-- -->. |
+|  [block](./kibana-plugin-core-public.scopedhistory.block.md) |  | <code>(prompt?: string &#124; boolean &#124; History.TransitionPromptHook&lt;HistoryLocationState&gt; &#124; undefined) =&gt; UnregisterCallback</code> | Add a block prompt requesting user confirmation when navigating away from the current page. |
 |  [createHref](./kibana-plugin-core-public.scopedhistory.createhref.md) |  | <code>(location: LocationDescriptorObject&lt;HistoryLocationState&gt;, { prependBasePath }?: {</code><br/><code>        prependBasePath?: boolean &#124; undefined;</code><br/><code>    }) =&gt; Href</code> | Creates an href (string) to the location. If <code>prependBasePath</code> is true (default), it will prepend the location's path with the scoped history basePath. |
 |  [createSubHistory](./kibana-plugin-core-public.scopedhistory.createsubhistory.md) |  | <code>&lt;SubHistoryLocationState = unknown&gt;(basePath: string) =&gt; ScopedHistory&lt;SubHistoryLocationState&gt;</code> | Creates a <code>ScopedHistory</code> for a subpath of this <code>ScopedHistory</code>. Useful for applications that may have sub-apps that do not need access to the containing application's history. |
 |  [go](./kibana-plugin-core-public.scopedhistory.go.md) |  | <code>(n: number) =&gt; void</code> | Send the user forward or backwards in the history stack. |

docs/development/plugins/data/public/kibana-plugin-plugins-data-public.searchsourcefields.md

@@ -32,6 +32,7 @@ export interface SearchSourceFields
 |  [source](./kibana-plugin-plugins-data-public.searchsourcefields.source.md) | <code>NameList</code> |  |
 |  [terminate\_after](./kibana-plugin-plugins-data-public.searchsourcefields.terminate_after.md) | <code>number</code> |  |
 |  [timeout](./kibana-plugin-plugins-data-public.searchsourcefields.timeout.md) | <code>string</code> |  |
+|  [trackTotalHits](./kibana-plugin-plugins-data-public.searchsourcefields.tracktotalhits.md) | <code>boolean &#124; number</code> |  |
 |  [type](./kibana-plugin-plugins-data-public.searchsourcefields.type.md) | <code>string</code> |  |
 |  [version](./kibana-plugin-plugins-data-public.searchsourcefields.version.md) | <code>boolean</code> |  |
 

docs/development/plugins/data/public/kibana-plugin-plugins-data-public.searchsourcefields.tracktotalhits.md

@@ -0,0 +1,11 @@
+<!-- Do not edit this file. It is automatically generated by API Documenter. -->
+
+[Home](./index.md) &gt; [kibana-plugin-plugins-data-public](./kibana-plugin-plugins-data-public.md) &gt; [SearchSourceFields](./kibana-plugin-plugins-data-public.searchsourcefields.md) &gt; [trackTotalHits](./kibana-plugin-plugins-data-public.searchsourcefields.tracktotalhits.md)
+
+## SearchSourceFields.trackTotalHits property
+
+<b>Signature:</b>
+
+```typescript
+trackTotalHits?: boolean | number;
+```

docs/user/alerting/defining-alerts.asciidoc

@@ -22,12 +22,16 @@ image::images/alert-flyout-sections.png[The three sections of an alert definitio
 All alert share the following four properties in common:
 
 [role="screenshot"]
-image::images/alert-flyout-general-details.png[alt='All alerts have name, tags, check every, and notify every properties in common']
+image::images/alert-flyout-general-details.png[alt='All alerts have name, tags, check every, and notify properties in common']
 
 Name::      The name of the alert. While this name does not have to be unique, the name can be referenced in actions and also appears in the searchable alert listing in the management UI. A distinctive name can help identify and find an alert.
 Tags::      A list of tag names that can be applied to an alert. Tags can help you organize and find alerts, because tags appear in the alert listing in the management UI which is searchable by tag.
 Check every::      This value determines how frequently the alert conditions below are checked. Note that the timing of background alert checks are not guaranteed, particularly for intervals of less than 10 seconds. See <<alerting-production-considerations>> for more information.
-Notify every::      This value limits how often actions are repeated when an alert instance remains active across alert checks. See <<alerting-concepts-suppressing-duplicate-notifications>> for more information.
+Notify::      This value limits how often actions are repeated when an alert instance remains active across alert checks. See <<alerting-concepts-suppressing-duplicate-notifications>> for more information. +
+- **Only on status change**: Actions are not repeated when an alert instance remains active across checks. Actions run only when the alert status changes.
+- **Every time alert is active**: Actions are repeated when an alert instance remains active across checks.
+- **On a custom action interval**: Actions are suppressed for the throttle interval, but repeat when an alert instance remains active across checks for a duration longer than the throttle interval.
+
 
 [float]
 [[defining-alerts-type-conditions]]