Merge branch 'master' into fix_rule_typo

.github/workflows/pr-project-assigner.yml

@@ -8,7 +8,7 @@ jobs:
     name: Assign a PR to project based on label
     steps:
       - name: Assign to project
-        uses: elastic/github-actions/[email protected].1
+        uses: elastic/github-actions/[email protected].2
         id: project_assigner
         with:
           issue-mappings: |

.github/workflows/project-assigner.yml

@@ -8,7 +8,7 @@ jobs:
     name: Assign issue or PR to project based on label
     steps:
       - name: Assign to project
-        uses: elastic/github-actions/[email protected].1
+        uses: elastic/github-actions/[email protected].2
         id: project_assigner
         with:
           issue-mappings: '[{"label": "Team:AppArch", "projectName": "kibana-app-arch", "columnId": 6173895}, {"label": "Feature:Lens", "projectName": "Lens", "columnId": 6219363}, {"label": "Team:Canvas", "projectName": "canvas", "columnId": 6187593}]'

.i18nrc.json

@@ -33,6 +33,7 @@
     "navigation": "src/plugins/navigation",
     "newsfeed": "src/plugins/newsfeed",
     "regionMap": "src/legacy/core_plugins/region_map",
+    "savedObjects": "src/plugins/saved_objects",
     "server": "src/legacy/server",
     "statusPage": "src/legacy/core_plugins/status_page",
     "telemetry": "src/legacy/core_plugins/telemetry",

docs/management/advanced-options.asciidoc

@@ -1,7 +1,7 @@
 [[advanced-options]]
-== Setting advanced options
+== Advanced Settings
 
-The *Advanced Settings* page enables you to directly edit settings that control the behavior of the Kibana application.
+The *Advanced Settings* UI enables you to edit settings that control the behavior of Kibana.
 For example, you can change the format used to display dates, specify the default index pattern, and set the precision
 for displayed decimal values.
 

docs/management/index-lifecycle-policies/intro-to-lifecycle-policies.asciidoc

@@ -1,30 +1,30 @@
 [role="xpack"]
 [[index-lifecycle-policies]]
-== Index lifecycle policies
+== Index Lifecycle Policies
 
-If you're working with time series data, you don't want to continually dump 
-everything into a single index. Instead, you might periodically roll over the 
-data to a new index to keep it from growing so big it's slow and expensive. 
-As the index ages and you query it less frequently, you’ll likely move it to 
+If you're working with time series data, you don't want to continually dump
+everything into a single index. Instead, you might periodically roll over the
+data to a new index to keep it from growing so big it's slow and expensive.
+As the index ages and you query it less frequently, you’ll likely move it to
 less expensive hardware and reduce the number of shards and replicas.
 
-To automatically move an index through its lifecycle, you can create a policy 
-to define actions to perform on the index as it ages. Index lifecycle policies 
-are especially useful when working with {beats-ref}/beats-reference.html[Beats] 
-data shippers, which continually 
-send operational data, such as metrics and logs, to Elasticsearch. You can 
-automate a rollover to a new index when the existing index reaches a specified 
-size or age.  This ensures that all indices have a similar size instead of having 
-daily indices where size can vary based on the number of Beats and the number 
+To automatically move an index through its lifecycle, you can create a policy
+to define actions to perform on the index as it ages. Index lifecycle policies
+are especially useful when working with {beats-ref}/beats-reference.html[Beats]
+data shippers, which continually
+send operational data, such as metrics and logs, to Elasticsearch. You can
+automate a rollover to a new index when the existing index reaches a specified
+size or age.  This ensures that all indices have a similar size instead of having
+daily indices where size can vary based on the number of Beats and the number
 of events sent.
 
-{kib}’s *Index Lifecycle Policies* walks you through the process for creating 
-and configuring a policy. Before using this feature, you should be familiar 
+{kib}’s *Index Lifecycle Policies* walks you through the process for creating
+and configuring a policy. Before using this feature, you should be familiar
 with index lifecycle management:
 
-* For an introduction, see 
-{ref}/getting-started-index-lifecycle-management.html[Getting started with index 
-lifecycle management].  
-* To dig into the concepts and technical details, see 
+* For an introduction, refer to
+{ref}/getting-started-index-lifecycle-management.html[Getting started with index
+lifecycle management].
+* To dig into the concepts and technical details, see
 {ref}/index-lifecycle-management.html[Managing the index lifecycle].
 * To check out the APIs, see {ref}/index-lifecycle-management-api.html[Index lifecycle management API].

docs/management/index-patterns.asciidoc

@@ -89,39 +89,11 @@ pattern: `*:logstash-*`.
 Once an index pattern is configured using the {ccs} syntax, all searches and
 aggregations using that index pattern in {kib} take advantage of {ccs}.
 
+
 [float]
+[[reload-fields]]
 === Manage your index pattern
 
-Once you create an index pattern, manually or with a sample data set,
-you can look at its fields and associated data types.
-You can also perform housekeeping tasks, such as making the
-index pattern the default or deleting it when you longer need it.
-To drill down into the details of an index pattern, click its name in
-the *Index patterns* overview.
-
-[role="screenshot"]
-image:management/index-patterns/images/new-index-pattern.png["Index files and data types"]
-
-From the detailed view, you can perform the following actions:
-
-* *Manage the index fields.* You can add formatters to format values and create
-scripted fields.
-See <<managing-fields, Managing fields>> for more information.
-
-* [[set-default-pattern]]*Set the default index pattern.* {kib} uses a badge to make users
-aware of which index pattern is the default. The first pattern
-you create is automatically designated as the default pattern. The default
-index pattern is loaded when you open *Discover*.
-
-* [[reload-fields]]*Refresh the index fields list.* You can refresh the index fields list to
-pick up any newly-added fields. Doing so also resets Kibana’s popularity counters
-for the fields. The popularity counters are used in *Discover* to sort fields in lists.
-
-* [[delete-pattern]]*Delete the index pattern.* This action removes the pattern from the list of
-Saved Objects in {kib}. You will not be able to recover field formatters,
-scripted fields, source filters, and field popularity data associated with the index pattern.
-Deleting an index pattern does
-not remove any indices or data documents from {es}.
-+
-WARNING: Deleting an index pattern breaks all visualizations, saved searches, and
-other saved objects that reference the pattern.
+To drill down into the fields and associated data types in an index pattern,
+click its name in the *Index patterns* overview page.
+For more information, refer to <<managing-fields, Index Patterns and Fields>>.

docs/management/managing-beats.asciidoc

@@ -1,6 +1,6 @@
 [[managing-beats]]
 [role="xpack"]
-== Managing {beats}
+== {beats} Central Management
 
 include::{asciidoc-dir}/../../shared/discontinued.asciidoc[tag=cm-discontinued]
 
@@ -34,14 +34,14 @@ Central Management UI.
 
 You need to enroll {beats} to register them in central management and establish
 trust. Enrolled {beats} will have the credentials needed to retrieve
-configurations from {kib}. 
+configurations from {kib}.
 
 [float]
 === Create configuration tags
 
 A _configuration tag_ is a group of configuration blocks that you can apply to
 one or more {beats}. For example, you can create a tag called `development` to
-group configurations for {beats} running in your development environment. 
+group configurations for {beats} running in your development environment.
 
 The first time you walk through the enrollment process, you'll create a
 configuration tag that's applied to the {beats} instance you're enrolling.
@@ -62,7 +62,7 @@ Central management supports configuration settings for:
 * {filebeat} modules
 * {metricbeat} modules
 * {filebeat} inputs
-* {filebeat} and {metricbeat} outputs 
+* {filebeat} and {metricbeat} outputs
 
 NOTE: Central management supports the following outputs only: {es}, {ls}, Kafka,
 and Redis. Other output types are not supported for {beats} that are enrolled in
@@ -72,7 +72,7 @@ Use the Central Management UI to define and manage settings for supported
 configuration blocks. You cannot define those settings in local {beats}
 configuration files. For configuration blocks that are not supported by central
 management, configure the settings in the local configuration file after
-enrolling the Beat in central management. 
+enrolling the Beat in central management.
 
 [float]
 === Manage enrolled {beats}

docs/management/managing-fields.asciidoc

@@ -1,12 +1,56 @@
 [[managing-fields]]
-== Managing Fields
+== Index Patterns and Fields
 
-The fields for the index pattern are listed in a table. Click a column header to sort the table by that column. Click
-the *Controls* button in the rightmost column for a given field to edit the field's properties. You can manually set
-the field's format from the *Format* drop-down. Format options vary based on the field's type.
+The *Index patterns* UI helps you create and manage
+the index patterns that retrieve your data from Elasticsearch.
 
-You can also set the field's popularity value in the *Popularity* text entry box to any desired value. Click the
-*Update Field* button to confirm your changes or *Cancel* to return to the list of fields.
+[role="screenshot"]
+image::images/management-index-patterns.png[]
+
+[float]
+=== Create an index pattern
+
+An index pattern is the glue that connects Kibana to your Elasticsearch data. Create an
+index pattern whenever you load your own data into Kibana. To get started,
+click *Create index pattern*, and then follow the guided steps. Refer to
+<<index-patterns, Creating an index pattern>> for the types of index patterns
+that you can create.
+
+[float]
+=== Manage your index pattern
+
+To view the fields and associated data types in an index pattern, click its name in
+the *Index patterns* overview.
+
+[role="screenshot"]
+image::management/index-patterns/images/new-index-pattern.png["Index files and data types"]
+
+Use the icons in the upper right to perform the following actions:
+
+* [[set-default-pattern]]*Set the default index pattern.* {kib} uses a badge to make users
+aware of which index pattern is the default. The first pattern
+you create is automatically designated as the default pattern. The default
+index pattern is loaded when you open *Discover*.
+
+* *Refresh the index fields list.* You can refresh the index fields list to
+pick up any newly-added fields. Doing so also resets Kibana’s popularity counters
+for the fields. The popularity counters are used in *Discover* to sort fields in lists.
+
+* [[delete-pattern]]*Delete the index pattern.* This action removes the pattern from the list of
+Saved Objects in {kib}. You will not be able to recover field formatters,
+scripted fields, source filters, and field popularity data associated with the index pattern.
+Deleting an index pattern does
+not remove any indices or data documents from {es}.
++
+WARNING: Deleting an index pattern breaks all visualizations, saved searches, and
+other saved objects that reference the pattern.
+
+[float]
+=== Edit a field
+
+To edit a field's properties, click the edit icon
+image:management/index-patterns/images/edit_icon.png[] in the detail view.
+You can set the field's format and popularity value.
 
 Kibana has field formatters for the following field types:
 

docs/management/managing-indices.asciidoc

@@ -1,6 +1,6 @@
 [role="xpack"]
 [[managing-indices]]
-== Index management
+== Index Management
 
 *Index Management* enables you to view index settings,
 mappings, and statistics and perform index-level operations.
@@ -127,7 +127,7 @@ under the *Mapped fields* tab as follows:
 image::images/management-index-templates-mappings.png[Mapped fields page]
 
 You can create additional mapping configurations in the *Dynamic templates* and
-*Advanced options* tabs. No additional mappings are required for this example. 
+*Advanced options* tabs. No additional mappings are required for this example.
 
 In the fourth step, define an alias named `logstash`.
 

docs/management/managing-licenses.asciidoc

@@ -1,32 +1,32 @@
 [[managing-licenses]]
-== License management
+== License Management
 
 When you install the default distribution of {kib}, you receive a basic license
 with no expiration date. For the full list of free features that are included in
-the basic license, see https://www.elastic.co/subscriptions[the subscription page].
+the basic license, refer to https://www.elastic.co/subscriptions[the subscription page].
 
 If you want to try out the full set of platinum features, you can activate a
-30-day trial license. Go to *Management > License Management* to view the 
+30-day trial license. Go to *Management > License Management* to view the
 status of your license, start a trial, or install a new license.
 
 NOTE: You can start a trial only if your cluster has not already activated a
 trial license for the current major product version. For example, if you have
-already activated a trial for v6.0, you cannot start a new trial until 
-v7.0. You can, however, contact `[email protected]` to request an extended trial
+already activated a trial for 6.0, you cannot start a new trial until
+7.0. You can, however, contact `[email protected]` to request an extended trial
 license.
 
-When you activate a new license level, new features appear in the left sidebar 
+When you activate a new license level, new features appear in the left sidebar
 of the *Management* page.
 
 [role="screenshot"]
 image::images/management-license.png[]
 
 At the end of the trial period, the platinum features operate in a
-<<license-expiration,degraded mode>>. You can revert to a basic license, 
-extend the trial, or purchase a subscription. 
+<<license-expiration,degraded mode>>. You can revert to a basic license,
+extend the trial, or purchase a subscription.
 
-TIP: If {security-features} are enabled, unless you have a trial license, 
-you must configure Transport Layer Security (TLS) in {es}. 
+TIP: If {security-features} are enabled, unless you have a trial license,
+you must configure Transport Layer Security (TLS) in {es}.
 See {ref}/encrypting-communications.html[Encrypting communications].
 {kib} and the {ref}/start-basic.html[start basic API] provide a list of all of
 the features that will no longer be supported if you revert to a basic license.
@@ -42,7 +42,7 @@ file that you install in {kib} or by using the
 
 TIP: If you are using a basic or trial license, {security-features} are disabled
 by default. In all other licenses, {security-features} are enabled by default;
-you must secure the {stack} or disable the {security-features}. 
+you must secure the {stack} or disable the {security-features}.
 
 [discrete]
 [[license-expiration]]
@@ -97,7 +97,7 @@ cluster.
 and start {dfeeds} are disabled.
 * All started {dfeeds} are stopped.
 * All open {anomaly-jobs} are closed.
-* APIs to create and start {dfanalytics-jobs} are disabled. 
+* APIs to create and start {dfanalytics-jobs} are disabled.
 * Existing {anomaly-job} and {dfanalytics-job} results continue to be available
 by using {kib} or APIs.
 

docs/management/managing-remote-clusters.asciidoc

@@ -1,8 +1,8 @@
 [[working-remote-clusters]]
-== Working with remote clusters
+== Remote Clusters
 
-{kib} *Management* provides user interfaces for working with data from remote 
-clusters and managing the {ccr} process. You can replicate indices from a 
+{kib} *Management* provides user interfaces for working with data from remote
+clusters and managing the {ccr} process. You can replicate indices from a
 leader remote cluster to a follower index in a local cluster. The local follower indices
 can be used to provide remote backups for disaster recovery or for geo-proximite copies of data.
 
@@ -14,51 +14,51 @@ Before using these features, you should be familiar with the following concepts:
 
 [float]
 [[managing-remote-clusters]]
-== Managing remote clusters 
+== Managing remote clusters
 
-*Remote clusters* helps you manage remote clusters for use with 
-{ccs} and {ccr}. You can add and remove remote clusters and check their connectivity. 
+*Remote clusters* helps you manage remote clusters for use with
+{ccs} and {ccr}. You can add and remove remote clusters and check their connectivity.
+
+Before you use this feature, you should be familiar with the concept of
+{ref}/modules-remote-clusters.html[remote clusters].
 
-Before you use this feature, you should be familiar with the concept of 
-{ref}/modules-remote-clusters.html[remote clusters].  
-
 Go to *Management > Elasticsearch > Remote clusters* to create or manage your remotes.
 
-To set up a new remote, click *Add a remote cluster*. Give the cluster a unique name 
-and define the seed nodes for cluster discovery. You can edit or remove your remote clusters 
+To set up a new remote, click *Add a remote cluster*. Give the cluster a unique name
+and define the seed nodes for cluster discovery. You can edit or remove your remote clusters
 from the *Remote clusters* list view.
 
 [role="screenshot"]
 image::images/add_remote_cluster.png[][UI for adding a remote cluster]
 
-Once a remote cluster is registered, you can use the tools under *{ccr-cap}* 
-to add and manage follower indices on the local cluster, and replicate data from 
+Once a remote cluster is registered, you can use the tools under *{ccr-cap}*
+to add and manage follower indices on the local cluster, and replicate data from
 indices on the remote cluster based on an auto-follow index pattern.
 
 [float]
 [[managing-cross-cluster-replication]]
 == [xpack]#Managing {ccr}#
 
-*{ccr-cap}* helps you create and manage the {ccr} process. 
-If you want to replicate data from existing indices, or set up 
-local followers on a case-by-case basis, go to *Follower indices*. 
-If you want to automatically detect and follow new indices when they are created 
-on a remote cluster, you can do so from *Auto-follow patterns*. 
+*{ccr-cap}* helps you create and manage the {ccr} process.
+If you want to replicate data from existing indices, or set up
+local followers on a case-by-case basis, go to *Follower indices*.
+If you want to automatically detect and follow new indices when they are created
+on a remote cluster, you can do so from *Auto-follow patterns*.
 
-Creating an auto-follow pattern is useful when you have time-series data, like a logs index, on the 
-remote cluster that is created or rolled over on a daily basis. Once you have configured an 
-auto-follow pattern, any time a new index with a name that matches the pattern is 
+Creating an auto-follow pattern is useful when you have time-series data, like a logs index, on the
+remote cluster that is created or rolled over on a daily basis. Once you have configured an
+auto-follow pattern, any time a new index with a name that matches the pattern is
 created in the remote cluster, a follower index is automatically configured in the local cluster.
 
-From the same view, you can also see a list of your saved auto-follow patterns for 
+From the same view, you can also see a list of your saved auto-follow patterns for
 a given remote cluster, and monitor whether the replication is active.
 
 Before you use these features, you should be familiar with the following concepts:
 
-* {ref}/ccr-requirements.html[Requirements for leader indices] 
+* {ref}/ccr-requirements.html[Requirements for leader indices]
 * {ref}/ccr-auto-follow.html[Automatically following indices]
 
-To get started, go to *Management > Elasticsearch > {ccr-cap}*. 
+To get started, go to *Management > Elasticsearch > {ccr-cap}*.
 
 [role="screenshot"]
 image::images/auto_follow_pattern.png[][UI for adding an auto-follow pattern]