Merge remote-tracking branch 'upstream/master' into 55652-url-fix

.github/CODEOWNERS

@@ -12,28 +12,23 @@
 /src/legacy/core_plugins/kibana/public/discover/ @elastic/kibana-app
 /src/legacy/core_plugins/kibana/public/visualize/ @elastic/kibana-app
 /src/legacy/core_plugins/kibana/public/local_application_service/ @elastic/kibana-app
-/src/legacy/core_plugins/kibana/public/home/ @elastic/kibana-app
 /src/legacy/core_plugins/kibana/public/dev_tools/ @elastic/kibana-app
 /src/legacy/core_plugins/metrics/ @elastic/kibana-app
 /src/legacy/core_plugins/vis_type_vislib/ @elastic/kibana-app
 # Exclude tutorials folder for now because they are not owned by Kibana app and most will move out soon
 /src/plugins/home/public @elastic/kibana-app
 /src/plugins/home/server/*.ts @elastic/kibana-app
 /src/plugins/home/server/services/ @elastic/kibana-app
+# Exclude tutorial resources folder for now because they are not owned by Kibana app and most will move out soon
+/src/legacy/core_plugins/kibana/public/home/*.ts @elastic/kibana-app
+/src/legacy/core_plugins/kibana/public/home/*.scss @elastic/kibana-app
+/src/legacy/core_plugins/kibana/public/home/np_ready/ @elastic/kibana-app
 /src/plugins/kibana_legacy/ @elastic/kibana-app
 /src/plugins/timelion/ @elastic/kibana-app
 /src/plugins/dev_tools/ @elastic/kibana-app
 
 # App Architecture
-/src/plugins/data/ @elastic/kibana-app-arch
-/src/plugins/embeddable/ @elastic/kibana-app-arch
-/src/plugins/expressions/ @elastic/kibana-app-arch
-/src/plugins/kibana_react/ @elastic/kibana-app-arch
-/src/plugins/kibana_utils/ @elastic/kibana-app-arch
-/src/plugins/navigation/ @elastic/kibana-app-arch
-/src/plugins/ui_actions/ @elastic/kibana-app-arch
-/src/plugins/visualizations/ @elastic/kibana-app-arch
-/x-pack/plugins/advanced_ui_actions/ @elastic/kibana-app-arch
+/packages/kbn-interpreter/ @elastic/kibana-app-arch
 /src/legacy/core_plugins/data/ @elastic/kibana-app-arch
 /src/legacy/core_plugins/elasticsearch/lib/create_proxy.js @elastic/kibana-app-arch
 /src/legacy/core_plugins/embeddable_api/ @elastic/kibana-app-arch
@@ -45,6 +40,19 @@
 /src/legacy/core_plugins/kibana/server/routes/api/suggestions/ @elastic/kibana-app-arch
 /src/legacy/core_plugins/visualizations/ @elastic/kibana-app-arch
 /src/legacy/server/index_patterns/ @elastic/kibana-app-arch
+/src/plugins/bfetch/ @elastic/kibana-app-arch
+/src/plugins/dashboard_embeddable_container/ @elastic/kibana-app-arch
+/src/plugins/data/ @elastic/kibana-app-arch
+/src/plugins/embeddable/ @elastic/kibana-app-arch
+/src/plugins/expressions/ @elastic/kibana-app-arch
+/src/plugins/inspector/ @elastic/kibana-app-arch
+/src/plugins/kibana_react/ @elastic/kibana-app-arch
+/src/plugins/kibana_utils/ @elastic/kibana-app-arch
+/src/plugins/management/ @elastic/kibana-app-arch
+/src/plugins/navigation/ @elastic/kibana-app-arch
+/src/plugins/ui_actions/ @elastic/kibana-app-arch
+/src/plugins/visualizations/ @elastic/kibana-app-arch
+/x-pack/plugins/advanced_ui_actions/ @elastic/kibana-app-arch
 
 # APM
 /x-pack/legacy/plugins/apm/  @elastic/apm-ui
@@ -150,9 +158,9 @@
 **/*.scss  @elastic/kibana-design
 
 # Elasticsearch UI
-/src/legacy/core_plugins/console/  @elastic/es-ui
+/src/plugins/console/  @elastic/es-ui
 /src/plugins/es_ui_shared/  @elastic/es-ui
-/x-pack/legacy/plugins/console_extensions/  @elastic/es-ui
+/x-pack/plugins/console_extensions/  @elastic/es-ui
 /x-pack/legacy/plugins/cross_cluster_replication/  @elastic/es-ui
 /x-pack/legacy/plugins/index_lifecycle_management/  @elastic/es-ui
 /x-pack/legacy/plugins/index_management/  @elastic/es-ui

.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/project-assigner@v1.0.0
+        uses: elastic/github-actions/project-assigner@v1.0.1
         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/project-assigner@v1.0.0
+        uses: elastic/github-actions/project-assigner@v1.0.1
         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

@@ -1,7 +1,7 @@
 {
   "paths": {
     "common.ui": "src/legacy/ui",
-    "console": "src/legacy/core_plugins/console",
+    "console": "src/plugins/console",
     "core": "src/core",
     "dashboardEmbeddableContainer": "src/plugins/dashboard_embeddable_container",
     "data": [
@@ -40,7 +40,7 @@
     "visTypeMetric": "src/legacy/core_plugins/vis_type_metric",
     "visTypeTable": "src/legacy/core_plugins/vis_type_table",
     "visTypeTagCloud": "src/legacy/core_plugins/vis_type_tagcloud",
-    "visTypeTimeseries": "src/legacy/core_plugins/vis_type_timeseries",
+    "visTypeTimeseries": ["src/legacy/core_plugins/vis_type_timeseries", "src/plugins/vis_type_timeseries"],
     "visTypeVega": "src/legacy/core_plugins/vis_type_vega",
     "visTypeVislib": "src/legacy/core_plugins/vis_type_vislib",
     "visualizations": [

docs/management/watcher-ui/index.asciidoc

@@ -34,7 +34,7 @@ If the {es} {security-features} are enabled, you must have the
 {ref}/security-privileges.html[`manage_watcher` or `monitor_watcher`]
 cluster privileges to use Watcher in {kib}.
 
-Alternately, you can have the built-in `kibana_user` role
+Alternately, you can have the built-in `kibana_admin` role
 and either of these watcher roles:
 
 * `watcher_admin`. You can perform all Watcher actions, including create and edit watches.

docs/migration/migrate_8_0.asciidoc

@@ -80,6 +80,21 @@ specified explicitly.
 
 *Impact:* Any workflow that involved manually clearing generated bundles will have to be updated with the new path.
 
+[float]
+[[breaking_80_user_role_changes]]
+=== User role changes
+
+[float]
+==== `kibana_user` role has been removed and `kibana_admin` has been added.
+
+*Details:* The `kibana_user` role has been removed and `kibana_admin` has been added to better
+reflect its intended use. This role continues to grant all access to every
+{kib} feature. If you wish to restrict access to specific features, create
+custom roles with {kibana-ref}/kibana-privileges.html[{kib} privileges].
+
+*Impact:* Any users currently assigned the `kibana_user` role will need to
+instead be assigned the `kibana_admin` role to maintain their current
+access level.
 
 [float]
 [[breaking_80_reporting_changes]]

docs/plugins/known-plugins.asciidoc

@@ -20,6 +20,7 @@ This list of plugins is not guaranteed to work on your version of Kibana. Instea
 * https://github.com/johtani/analyze-api-ui-plugin[Analyze UI] (johtani) - UI for elasticsearch _analyze API
 * https://github.com/TrumanDu/cleaner[Cleaner] (TrumanDu)- Setting index ttl.
 * https://github.com/bitsensor/elastalert-kibana-plugin[ElastAlert Kibana Plugin] (BitSensor) - UI to create, test and edit ElastAlert rules
+* https://github.com/query-ai/queryai-kibana-plugin[AI Analyst] (Query.AI) - App providing: NLP queries, automation, ML visualizations and insights
 
 [float]
 === Timelion Extensions

docs/settings/monitoring-settings.asciidoc

@@ -14,7 +14,7 @@ built-in `elastic` user has this role.
 
 You can adjust how monitoring data is
 collected from {kib} and displayed in {kib} by configuring settings in the
-`kibana.yml` file. There are also `xpack.monitoring.elasticsearch.*` settings,
+`kibana.yml` file. There are also `monitoring.ui.elasticsearch.*` settings,
 which support the same values as <<settings,{kib} configuration settings>>.
 
 To control how data is collected from your {es} nodes, you configure
@@ -31,20 +31,20 @@ For more information, see
 [[monitoring-general-settings]]
 ==== General monitoring settings
 
-`xpack.monitoring.enabled`::
+`monitoring.enabled`::
 Set to `true` (default) to enable the {monitor-features} in {kib}. Unlike the
-`xpack.monitoring.ui.enabled` setting, when this setting is `false`, the
+`monitoring.ui.enabled` setting, when this setting is `false`, the
 monitoring back-end does not run and {kib} stats are not sent to the monitoring
 cluster.
 
-`xpack.monitoring.elasticsearch.hosts`::
+`monitoring.ui.elasticsearch.hosts`::
 Specifies the location of the {es} cluster where your monitoring data is stored.
 By default, this is the same as `elasticsearch.hosts`. This setting enables
 you to use a single {kib} instance to search and visualize data in your
 production cluster as well as monitor data sent to a dedicated monitoring
 cluster.
 
-`xpack.monitoring.elasticsearch.username`::
+`monitoring.ui.elasticsearch.username`::
 Specifies the username used by {kib} monitoring to establish a persistent connection
 in {kib}  to the {es} monitoring cluster and to verify licensing status on the {es}
 monitoring cluster.
@@ -55,7 +55,7 @@ both the {es} monitoring cluster and the {es} production cluster.
 
 If not set, {kib} uses the value of the `elasticsearch.username` setting.
 
-`xpack.monitoring.elasticsearch.password`::
+`monitoring.ui.elasticsearch.password`::
 Specifies the password used by {kib} monitoring to establish a persistent connection
 in {kib}  to the {es} monitoring cluster and to verify licensing status on the {es}
 monitoring cluster.
@@ -66,7 +66,7 @@ both the {es} monitoring cluster and the {es} production cluster.
 
 If not set, {kib} uses the value of the `elasticsearch.password` setting.
 
-`xpack.monitoring.elasticsearch.pingTimeout`::
+`monitoring.ui.elasticsearch.pingTimeout`::
 Specifies the time in milliseconds to wait for {es} to respond to internal
 health checks. By default, it matches the `elasticsearch.pingTimeout` setting,
 which has a default value of `30000`.
@@ -77,11 +77,11 @@ which has a default value of `30000`.
 
 These settings control how data is collected from {kib}.
 
-`xpack.monitoring.kibana.collection.enabled`::
+`monitoring.kibana.collection.enabled`::
 Set to `true` (default) to enable data collection from the {kib} NodeJS server
 for {kib} Dashboards to be featured in the Monitoring.
 
-`xpack.monitoring.kibana.collection.interval`::
+`monitoring.kibana.collection.interval`::
 Specifies the number of milliseconds to wait in between data sampling on the
 {kib} NodeJS server for the metrics that are displayed in the {kib} dashboards.
 Defaults to `10000` (10 seconds).
@@ -96,24 +96,24 @@ However, the defaults work best in most circumstances. For more information
 about configuring {kib}, see
 {kibana-ref}/settings.html[Setting Kibana Server Properties].
 
-`xpack.monitoring.elasticsearch.logFetchCount`::
+`monitoring.ui.elasticsearch.logFetchCount`::
 Specifies the number of log entries to display in the Monitoring UI. Defaults to
 `10`. The maximum value is `50`.
 
-`xpack.monitoring.max_bucket_size`::
+`monitoring.ui.max_bucket_size`::
 Specifies the number of term buckets to return out of the overall terms list when
 performing terms aggregations to retrieve index and node metrics. For more
 information about the `size` parameter, see
 {ref}/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-size[Terms Aggregation].
 Defaults to `10000`.
 
-`xpack.monitoring.min_interval_seconds`::
+`monitoring.ui.min_interval_seconds`::
 Specifies the minimum number of seconds that a time bucket in a chart can
 represent. Defaults to 10. If you modify the
-`xpack.monitoring.collection.interval` in `elasticsearch.yml`, use the same
+`monitoring.ui.collection.interval` in `elasticsearch.yml`, use the same
 value in this setting.
 
-`xpack.monitoring.ui.enabled`::
+`monitoring.ui.enabled`::
 Set to `false` to hide the Monitoring UI in {kib}. The monitoring back-end
 continues to run as an agent for sending {kib} stats to the monitoring
 cluster. Defaults to `true`.
@@ -127,15 +127,15 @@ better decisions about your container performance, rather than guessing based on
 the overall machine performance. If you are not running your applications in a
 container, then Cgroup statistics are not useful.
 
-`xpack.monitoring.ui.container.elasticsearch.enabled`::
+`monitoring.ui.container.elasticsearch.enabled`::
 
 For {es} clusters that are running in containers, this setting changes the
 *Node Listing* to display the CPU utilization based on the reported Cgroup
 statistics. It also adds the calculated Cgroup CPU utilization to the
 *Node Overview* page instead of the overall operating system's CPU
 utilization. Defaults to `false`.
 
-`xpack.monitoring.ui.container.logstash.enabled`::
+`monitoring.ui.container.logstash.enabled`::
 
 For {ls} nodes that are running in containers, this setting
 changes the {ls} *Node Listing* to display the CPU utilization

docs/uptime-guide/security.asciidoc

@@ -42,15 +42,15 @@ PUT /_security/role/uptime
 === Assign the role to a user
 
 Next, you'll need to create a user with both the `uptime` role, and another role with sufficient {kibana-ref}/kibana-privileges.html[Kibana privileges],
-such as the `kibana_user` role.
+such as the `kibana_admin` role.
 You can do this with the following request:
 
 ["source","sh",subs="attributes,callouts"]
 ---------------------------------------------------------------
 PUT /_security/user/jacknich
 {
   "password" : "j@rV1s",
-  "roles" : [ "uptime", "kibana_user" ],
+  "roles" : [ "uptime", "kibana_admin" ],
   "full_name" : "Jack Nicholson",
   "email" : "jacknich@example.com",
   "metadata" : {

docs/user/monitoring/viewing-metrics.asciidoc

@@ -63,7 +63,7 @@ remote monitoring cluster, you must use credentials that are valid on both the
 
 --
 
-.. Create users that have the `monitoring_user` and `kibana_user` 
+.. Create users that have the `monitoring_user` and `kibana_admin` 
 {ref}/built-in-roles.html[built-in roles].
 
 . Open {kib} in your web browser. 

docs/user/security/authorization/index.asciidoc

@@ -2,11 +2,11 @@
 [[xpack-security-authorization]]
 
 === Granting access to {kib}
-The Elastic Stack comes with the `kibana_user` {ref}/built-in-roles.html[built-in role], which you can use to grant access to all Kibana features in all spaces. To grant users access to a subset of spaces or features, you can create a custom role that grants the desired Kibana privileges. 
+The Elastic Stack comes with the `kibana_admin` {ref}/built-in-roles.html[built-in role], which you can use to grant access to all Kibana features in all spaces. To grant users access to a subset of spaces or features, you can create a custom role that grants the desired Kibana privileges. 
 
-When you assign a user multiple roles, the user receives a union of the roles’ privileges. Therefore, assigning the `kibana_user` role in addition to a custom role that grants Kibana privileges is ineffective because `kibana_user` has access to all the features in all spaces.
+When you assign a user multiple roles, the user receives a union of the roles’ privileges. Therefore, assigning the `kibana_admin` role in addition to a custom role that grants Kibana privileges is ineffective because `kibana_admin` has access to all the features in all spaces.
 
-NOTE: When running multiple tenants of Kibana by changing the `kibana.index` in your `kibana.yml`, you cannot use `kibana_user` to grant access. You must create custom roles that authorize the user for that specific tenant. Although multi-tenant installations are supported, the recommended approach to securing access to Kibana segments is to grant users access to specific spaces.
+NOTE: When running multiple tenants of Kibana by changing the `kibana.index` in your `kibana.yml`, you cannot use `kibana_admin` to grant access. You must create custom roles that authorize the user for that specific tenant. Although multi-tenant installations are supported, the recommended approach to securing access to Kibana segments is to grant users access to specific spaces.
 
 [role="xpack"]
 === {kib} role management

docs/user/security/reporting.asciidoc

@@ -85,14 +85,14 @@ elasticsearch.username: 'custom_kibana_system'
 [[reporting-roles-user-api]]
 ==== With the user API
 This example uses the {ref}/security-api-put-user.html[user API] to create a user who has the
-`reporting_user` role and the `kibana_user` role:
+`reporting_user` role and the `kibana_admin` role:
 
 [source, sh]
 ---------------------------------------------------------------
 POST /_security/user/reporter
 {
   "password" : "x-pack-test-password",
-  "roles" : ["kibana_user", "reporting_user"],
+  "roles" : ["kibana_admin", "reporting_user"],
   "full_name" : "Reporting User"
 }
 ---------------------------------------------------------------
@@ -106,11 +106,11 @@ roles on a per user basis, or assign roles to groups of users. By default, role
 mappings are configured in
 {ref}/mapping-roles.html[`config/shield/role_mapping.yml`].
 For example, the following snippet assigns the user named Bill Murray the
-`kibana_user` and `reporting_user` roles:
+`kibana_admin` and `reporting_user` roles:
 
 [source,yaml]
 --------------------------------------------------------------------------------
-kibana_user:
+kibana_admin:
   - "cn=Bill Murray,dc=example,dc=com"
 reporting_user:
   - "cn=Bill Murray,dc=example,dc=com"

docs/user/security/securing-kibana.asciidoc

@@ -104,15 +104,15 @@ You can manage privileges on the *Management / Security / Roles* page in {kib}.
 If you're using the native realm with Basic Authentication, you can assign roles
 using the *Management / Security / Users* page in {kib} or the
 {ref}/security-api.html#security-user-apis[user management APIs]. For example, 
-the following creates a user named `jacknich` and assigns it the `kibana_user` 
+the following creates a user named `jacknich` and assigns it the `kibana_admin` 
 role:
 
 [source,js]
 --------------------------------------------------------------------------------
 POST /_security/user/jacknich
 {
   "password" : "t0pS3cr3t",
-  "roles" : [ "kibana_user" ]
+  "roles" : [ "kibana_admin" ]
 }
 --------------------------------------------------------------------------------
 // CONSOLE