Merge remote-tracking branch 'upstream/master' into shim-oss-telemetry

Author: flash1293

.i18nrc.json

@@ -6,9 +6,9 @@
     "dashboardEmbeddableContainer": "src/plugins/dashboard_embeddable_container",
     "data": ["src/legacy/core_plugins/data", "src/plugins/data"],
     "embeddableApi": "src/plugins/embeddable",
+    "share": "src/plugins/share",
     "esUi": "src/plugins/es_ui_shared",
-    "expressions_np": "src/plugins/expressions",
-    "expressions": "src/legacy/core_plugins/expressions",
+    "expressions": "src/plugins/expressions",
     "inputControl": "src/legacy/core_plugins/input_control_vis",
     "inspector": "src/plugins/inspector",
     "inspectorViews": "src/legacy/core_plugins/inspector_views",
@@ -34,7 +34,7 @@
     "visTypeTagCloud": "src/legacy/core_plugins/vis_type_tagcloud",
     "visTypeTimeseries": "src/legacy/core_plugins/vis_type_timeseries",
     "visTypeVega": "src/legacy/core_plugins/vis_type_vega",
-    "visualizations": "src/plugins/visualizations"
+    "visualizations": ["src/plugins/visualizations", "src/legacy/core_plugins/visualizations"]
   },
   "exclude": ["src/legacy/ui/ui_render/ui_render_mixin.js"],
   "translations": []

CONTRIBUTING.md

@@ -325,7 +325,7 @@ Note that for VSCode, to enable "live" linting of TypeScript (and other) file ty
   "eslint.autoFixOnSave": true,
 ```
 
-It is **not** recommended to use `prettier` plugin on Kibana project. Because settings are in `eslintrc.js` file and it is applied to too many files that shouldn't be prettier-ized. 
+:warning: It is **not** recommended to use the [`Prettier` extension/IDE plugin](https://prettier.io/) while maintaining the Kibana project. Formatting and styling roles are set in the multiple `.eslintrc.js` files across the project and some of them use the [NPM version of Prettier](https://www.npmjs.com/package/prettier). Using the IDE extension might cause conflicts, applying the formatting to too many files that shouldn't be prettier-ized and/or highlighting errors that are actually OK.
 
 ### Internationalization
 

docs/canvas/canvas-share-workpad.asciidoc

@@ -55,7 +55,7 @@ image::images/canvas-create-URL.gif[Create POST URL]
 [[add-workpad-website]]
 === Share the workpad on a website
 
-beta[] Download the workpad and share it on any website, then customize the workpad behavior to autoplay the pages or hide the toolbar.
+beta[] Canvas allows you to create _shareables_, which are workpads that you download and securely share on any website. To customize the behavior of the workpad on your website, you can choose to autoplay the pages or hide the workpad toolbar.
 
 . If you are using a Gold or Platinum license, enable reporting in your `config/kibana.yml` file.
 
@@ -74,7 +74,7 @@ NOTE: Shareable workpads encode the current state of the workpad in a JSON file.
 
 [float]
 [[change-the-workpad-settings]]
-=== Change the shareable workpad settings
+=== Change the settings
 
 After you've added the workpad to your website, you can change the autoplay and toolbar settings.
 

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

@@ -15,11 +15,6 @@ export interface ChromeNavControl
 
 |  Property | Type | Description |
 |  --- | --- | --- |
+|  [mount](./kibana-plugin-public.chromenavcontrol.mount.md) | <code>MountPoint</code> |  |
 |  [order](./kibana-plugin-public.chromenavcontrol.order.md) | <code>number</code> |  |
 
-## Methods
-
-|  Method | Description |
-|  --- | --- |
-|  [mount(targetDomElement)](./kibana-plugin-public.chromenavcontrol.mount.md) |  |
-

docs/development/core/public/kibana-plugin-public.chromenavcontrol.mount.md

@@ -2,21 +2,10 @@
 
 [Home](./index.md) > [kibana-plugin-public](./kibana-plugin-public.md) > [ChromeNavControl](./kibana-plugin-public.chromenavcontrol.md) > [mount](./kibana-plugin-public.chromenavcontrol.mount.md)
 
-## ChromeNavControl.mount() method
+## ChromeNavControl.mount property
 
 <b>Signature:</b>
 
 ```typescript
-mount(targetDomElement: HTMLElement): () => void;
+mount: MountPoint;
 ```
-
-## Parameters
-
-|  Parameter | Type | Description |
-|  --- | --- | --- |
-|  targetDomElement | <code>HTMLElement</code> |  |
-
-<b>Returns:</b>
-
-`() => void`
-

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

@@ -9,5 +9,5 @@ A function that should mount DOM content inside the provided container element a
 <b>Signature:</b>
 
 ```typescript
-export declare type MountPoint = (element: HTMLElement) => UnmountCallback;
+export declare type MountPoint<T extends HTMLElement = HTMLElement> = (element: T) => UnmountCallback;
 ```

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

@@ -16,6 +16,6 @@ export interface OverlayStart
 |  Property | Type | Description |
 |  --- | --- | --- |
 |  [banners](./kibana-plugin-public.overlaystart.banners.md) | <code>OverlayBannersStart</code> | [OverlayBannersStart](./kibana-plugin-public.overlaybannersstart.md) |
-|  [openFlyout](./kibana-plugin-public.overlaystart.openflyout.md) | <code>(flyoutChildren: React.ReactNode, flyoutProps?: {</code><br/><code>        closeButtonAriaLabel?: string;</code><br/><code>        'data-test-subj'?: string;</code><br/><code>    }) =&gt; OverlayRef</code> |  |
-|  [openModal](./kibana-plugin-public.overlaystart.openmodal.md) | <code>(modalChildren: React.ReactNode, modalProps?: {</code><br/><code>        className?: string;</code><br/><code>        closeButtonAriaLabel?: string;</code><br/><code>        'data-test-subj'?: string;</code><br/><code>    }) =&gt; OverlayRef</code> |  |
+|  [openFlyout](./kibana-plugin-public.overlaystart.openflyout.md) | <code>OverlayFlyoutStart['open']</code> |  |
+|  [openModal](./kibana-plugin-public.overlaystart.openmodal.md) | <code>OverlayModalStart['open']</code> |  |
 

docs/development/core/public/kibana-plugin-public.overlaystart.openflyout.md

@@ -4,11 +4,9 @@
 
 ## OverlayStart.openFlyout property
 
+
 <b>Signature:</b>
 
 ```typescript
-openFlyout: (flyoutChildren: React.ReactNode, flyoutProps?: {
-        closeButtonAriaLabel?: string;
-        'data-test-subj'?: string;
-    }) => OverlayRef;
+openFlyout: OverlayFlyoutStart['open'];
 ```

docs/development/core/public/kibana-plugin-public.overlaystart.openmodal.md

@@ -4,12 +4,9 @@
 
 ## OverlayStart.openModal property
 
+
 <b>Signature:</b>
 
 ```typescript
-openModal: (modalChildren: React.ReactNode, modalProps?: {
-        className?: string;
-        closeButtonAriaLabel?: string;
-        'data-test-subj'?: string;
-    }) => OverlayRef;
+openModal: OverlayModalStart['open'];
 ```

docs/discover/kuery.asciidoc

@@ -19,14 +19,13 @@ they appear. This means documents with "quick brown fox" will match, but so will
 to search for a phrase.
 
 The query parser will no longer split on whitespace. Multiple search terms must be separated by explicit
-boolean operators. Note that boolean operators are not case sensitive.
+boolean operators. Lucene will combine search terms with an `or` by default, so `response:200 extension:php` would 
+become `response:200 or extension:php` in KQL. This will match documents where response matches 200, extension matches php, or both. 
+Note that boolean operators are not case sensitive.
 
-`response:200 extension:php` in lucene would become `response:200 and extension:php`.
- This will match documents where response matches 200 and extension matches php.
+We can make terms required by using `and`.
 
-We can make terms optional by using `or`.
-
-`response:200 or extension:php` will match documents where response matches 200, extension matches php, or both.
+`response:200 and extension:php` will match documents where response matches 200 and extension matches php.
 
 By default, `and` has a higher precedence than `or`.
 
@@ -73,7 +72,7 @@ set these terms will be matched against all fields. For example, a query for `re
 in the response field, but a query for just `200` will search for 200 across all fields in your index.
 ============
 
-===== Nested Field Support
+==== Nested Field Support
 
 KQL supports querying on {ref}/nested.html[nested fields] through a special syntax. You can query nested fields in subtly different
 ways, depending on the results you want, so crafting nested queries requires extra thought.
@@ -85,7 +84,8 @@ There are two main approaches to take:
 * *Parts of the query can match different nested documents.* This is how a regular object field works. 
  Although generally less useful, there might be occasions where you want to query a nested field in this way.
 
-Let's take a look at the first approach. In the following document, `items` is a nested field:
+Let's take a look at the first approach. In the following document, `items` is a nested field. Each document in the nested 
+field contains a name, stock, and category.
 
 [source,json]
 ----------------------------------
@@ -116,21 +116,38 @@ Let's take a look at the first approach. In the following document, `items` is a
 }
 ----------------------------------
 
+===== Match a single nested document
+
 To find stores that have more than 10 bananas in stock, you would write a query like this:
 
 `items:{ name:banana and stock > 10 }`
 
-`items` is the "nested path". Everything inside the curly braces (the "nested group") must match a single document. 
-For example, `items:{ name:banana and stock:9 }` does not match because there isn't a single nested document that 
-matches the entire query in the nested group. 
+`items` is the "nested path". Everything inside the curly braces (the "nested group") must match a single nested document. 
+
+The following example returns no matches because no single nested document has bananas with a stock of 9.
+
+`items:{ name:banana and stock:9 }`
+
+==== Match different nested documents
 
-What if you want to find a store with more than 10 bananas that *also* stocks vegetables? This is the second way of querying a nested field, and you can do it like this:
+The subqueries in this example are in separate nested groups and can match different nested documents.
+
+`items:{ name:banana } and items:{ stock:9 }`
+
+`name:banana` matches the first document in the array and `stock:9` matches the third document in the array.
+
+==== Combine approaches
+
+You can combine these two approaches to create complex queries. What if you wanted to find a store with more than 10 
+bananas that *also* stocks vegetables? You could do this:
 
 `items:{ name:banana and stock > 10 } and items:{ category:vegetable }`
 
 The first nested group (`name:banana and stock > 10`) must still match a single document, but the `category:vegetables`
 subquery can match a different nested document because it is in a separate group.
 
+==== Nested fields inside other nested fields
+
 KQL's syntax also supports nested fields inside of other nested fields—you simply have to specify the full path. Suppose you
 have a document where `level1` and `level2` are both nested fields: