Merge branch '7.x' into backport/7.x/pr-59982

.eslintrc.js

@@ -743,6 +743,19 @@ module.exports = {
       },
     },
 
+    /**
+     * Alerting Services overrides
+     */
+    {
+      // typescript only for front and back end
+      files: [
+        'x-pack/{,legacy/}plugins/{alerting,alerting_builtins,actions,task_manager,event_log}/**/*.{ts,tsx}',
+      ],
+      rules: {
+        '@typescript-eslint/no-explicit-any': 'error',
+      },
+    },
+
     /**
      * Lens overrides
      */

Jenkinsfile

@@ -11,7 +11,7 @@ kibanaPipeline(timeoutMinutes: 135, checkPrChanges: true) {
         'kibana-intake-agent': workers.intake('kibana-intake', './test/scripts/jenkins_unit.sh'),
         'x-pack-intake-agent': workers.intake('x-pack-intake', './test/scripts/jenkins_xpack.sh'),
         'kibana-oss-agent': workers.functional('kibana-oss-tests', { kibanaPipeline.buildOss() }, [
-          // 'oss-firefoxSmoke': kibanaPipeline.functionalTestProcess('kibana-firefoxSmoke', './test/scripts/jenkins_firefox_smoke.sh'),
+          'oss-firefoxSmoke': kibanaPipeline.functionalTestProcess('kibana-firefoxSmoke', './test/scripts/jenkins_firefox_smoke.sh'),
           'oss-ciGroup1': kibanaPipeline.ossCiGroupProcess(1),
           'oss-ciGroup2': kibanaPipeline.ossCiGroupProcess(2),
           'oss-ciGroup3': kibanaPipeline.ossCiGroupProcess(3),
@@ -28,7 +28,7 @@ kibanaPipeline(timeoutMinutes: 135, checkPrChanges: true) {
           // 'oss-visualRegression': kibanaPipeline.functionalTestProcess('visualRegression', './test/scripts/jenkins_visual_regression.sh'),
         ]),
         'kibana-xpack-agent': workers.functional('kibana-xpack-tests', { kibanaPipeline.buildXpack() }, [
-          // 'xpack-firefoxSmoke': kibanaPipeline.functionalTestProcess('xpack-firefoxSmoke', './test/scripts/jenkins_xpack_firefox_smoke.sh'),
+          'xpack-firefoxSmoke': kibanaPipeline.functionalTestProcess('xpack-firefoxSmoke', './test/scripts/jenkins_xpack_firefox_smoke.sh'),
           'xpack-ciGroup1': kibanaPipeline.xpackCiGroupProcess(1),
           'xpack-ciGroup2': kibanaPipeline.xpackCiGroupProcess(2),
           'xpack-ciGroup3': kibanaPipeline.xpackCiGroupProcess(3),

docs/developer/core/development-functional-tests.asciidoc

@@ -153,16 +153,16 @@ A test suite is a collection of tests defined by calling `describe()`, and then
 Use tags in `describe()` function to group functional tests. Tags include:
 * `ciGroup{id}` - Assigns test suite to a specific CI worker
 * `skipCloud` and `skipFirefox` - Excludes test suite from running on Cloud or Firefox
-* `smoke` - Groups tests that run on Chrome and Firefox
+* `includeFirefox` - Groups tests that run on Chrome and Firefox
 
 **Cross-browser testing**:::
-On CI, all the functional tests are executed in Chrome by default. To also run a suite against Firefox, assign the `smoke` tag:
+On CI, all the functional tests are executed in Chrome by default. To also run a suite against Firefox, assign the `includeFirefox` tag:
 
 ["source","js"]
 -----------
 // on CI test suite will be run twice: in Chrome and Firefox
 describe('My Cross-browser Test Suite', function () {
-  this.tags('smoke');
+  this.tags('includeFirefox');
 
   it('My First Test');
 }

docs/development/core/server/kibana-plugin-core-server.md

@@ -264,7 +264,7 @@ The plugin integrates with the core system via lifecycle events: `setup`<!-- -->
 |  [SavedObjectAttributeSingle](./kibana-plugin-core-server.savedobjectattributesingle.md) | Don't use this type, it's simply a helper type for [SavedObjectAttribute](./kibana-plugin-core-server.savedobjectattribute.md) |
 |  [SavedObjectMigrationFn](./kibana-plugin-core-server.savedobjectmigrationfn.md) | A migration function for a [saved object type](./kibana-plugin-core-server.savedobjectstype.md) used to migrate it to a given version |
 |  [SavedObjectSanitizedDoc](./kibana-plugin-core-server.savedobjectsanitizeddoc.md) |  |
-|  [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistance and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->\#\#\# 503s from missing index<!-- -->Unlike all other methods, create requests are supposed to succeed even when the Kibana index does not exist because it will be automatically created by elasticsearch. When that is not the case it is because Elasticsearch's <code>action.auto_create_index</code> setting prevents it from being created automatically so we throw a special 503 with the intention of informing the user that their Elasticsearch settings need to be updated.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
+|  [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistance and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
 |  [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md) | Describes the factory used to create instances of the Saved Objects Client. |
 |  [SavedObjectsClientFactoryProvider](./kibana-plugin-core-server.savedobjectsclientfactoryprovider.md) | Provider to invoke to retrieve a [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md)<!-- -->. |
 |  [SavedObjectsClientWrapperFactory](./kibana-plugin-core-server.savedobjectsclientwrapperfactory.md) | Describes the factory used to create instances of Saved Objects Client Wrappers. |

docs/development/core/server/kibana-plugin-core-server.savedobjectsclientcontract.md

@@ -30,10 +30,6 @@ At the time of writing we are in the process of transitioning away from the oper
 
 From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.
 
-\#\#\# 503s from missing index
-
-Unlike all other methods, create requests are supposed to succeed even when the Kibana index does not exist because it will be automatically created by elasticsearch. When that is not the case it is because Elasticsearch's `action.auto_create_index` setting prevents it from being created automatically so we throw a special 503 with the intention of informing the user that their Elasticsearch settings need to be updated.
-
 See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)
 
 <b>Signature:</b>

docs/development/core/server/kibana-plugin-core-server.savedobjectserrorhelpers.md

@@ -17,7 +17,6 @@ export declare class SavedObjectsErrorHelpers
 |  --- | --- | --- |
 |  [createBadRequestError(reason)](./kibana-plugin-core-server.savedobjectserrorhelpers.createbadrequesterror.md) | <code>static</code> |  |
 |  [createConflictError(type, id)](./kibana-plugin-core-server.savedobjectserrorhelpers.createconflicterror.md) | <code>static</code> |  |
-|  [createEsAutoCreateIndexError()](./kibana-plugin-core-server.savedobjectserrorhelpers.createesautocreateindexerror.md) | <code>static</code> |  |
 |  [createGenericNotFoundError(type, id)](./kibana-plugin-core-server.savedobjectserrorhelpers.creategenericnotfounderror.md) | <code>static</code> |  |
 |  [createInvalidVersionError(versionInput)](./kibana-plugin-core-server.savedobjectserrorhelpers.createinvalidversionerror.md) | <code>static</code> |  |
 |  [createUnsupportedTypeError(type)](./kibana-plugin-core-server.savedobjectserrorhelpers.createunsupportedtypeerror.md) | <code>static</code> |  |
@@ -31,7 +30,6 @@ export declare class SavedObjectsErrorHelpers
 |  [decorateRequestEntityTooLargeError(error, reason)](./kibana-plugin-core-server.savedobjectserrorhelpers.decoraterequestentitytoolargeerror.md) | <code>static</code> |  |
 |  [isBadRequestError(error)](./kibana-plugin-core-server.savedobjectserrorhelpers.isbadrequesterror.md) | <code>static</code> |  |
 |  [isConflictError(error)](./kibana-plugin-core-server.savedobjectserrorhelpers.isconflicterror.md) | <code>static</code> |  |
-|  [isEsAutoCreateIndexError(error)](./kibana-plugin-core-server.savedobjectserrorhelpers.isesautocreateindexerror.md) | <code>static</code> |  |
 |  [isEsCannotExecuteScriptError(error)](./kibana-plugin-core-server.savedobjectserrorhelpers.isescannotexecutescripterror.md) | <code>static</code> |  |
 |  [isEsUnavailableError(error)](./kibana-plugin-core-server.savedobjectserrorhelpers.isesunavailableerror.md) | <code>static</code> |  |
 |  [isForbiddenError(error)](./kibana-plugin-core-server.savedobjectserrorhelpers.isforbiddenerror.md) | <code>static</code> |  |

docs/logs/using.asciidoc

@@ -69,12 +69,19 @@ To highlight a word or phrase in the logs stream, click *Highlights* and enter y
 [float]
 [[logs-event-inspector]]
 === Inspect a log event
-To inspect a log event, hover over it, then click the *View details* icon image:logs/images/logs-view-event.png[View event icon] beside the event.
-This opens the *Log event document details* fly-out that shows the fields associated with the log event.
+To inspect a log event, hover over it, then click the *View actions for line* icon image:logs/images/logs-action-menu.png[View actions for line icon]. On the menu that opens, select *View details*. This opens the *Log event document details* fly-out that shows the fields associated with the log event.
 
 To quickly filter the logs stream by one of the field values, in the log event details, click the *View event with filter* icon image:logs/images/logs-view-event-with-filter.png[View event icon] beside the field.
 This automatically adds a search filter to the logs stream to filter the entries by this field and value.
 
+[float]
+[[log-view-in-context]]
+=== View log line in context
+To view a certain line in its context (for example, with other log lines from the same file, or the same cloud container), hover over it, then click the *View actions for line* image:logs/images/logs-action-menu.png[View actions for line icon]. On the menu that opens, select *View in context*. This opens the *View log in context* modal, that shows the log line in its context.
+
+[role="screenshot"]
+image::logs/images/logs-view-in-context.png[View a log line in context]
+
 [float]
 [[view-log-anomalies]]
 === View log anomalies

docs/release-notes/highlights-7.7.0.asciidoc

@@ -90,6 +90,19 @@ The distance filter is in addition to the tools for filtering data by custom sha
 [role="screenshot"]
 image:release-notes/images/7-7-maps-distance-filter.png[Distance filters in Elastic Maps]
 
+[float]
+[[file-uploader-highlights]]
+=== {data-viz} now recommends {filebeat} config
+
+experimental[] When you upload a file to the *{data-viz}*, a {filebeat} 
+configuration is recommended for you to use. You can then use {filebeat} to add 
+more data of the same structure to the same index that was created during an 
+initial upload.
+
+[role="screenshot"]
+image:release-notes/images/7-7-file-uploader-filebeat.png[Recommended Filebeat config in Data Vizualizer]
+For more information about *{data-viz}*, refer to <<xpack-ml>>.
+
 [float]
 === Learn more
 

docs/user/alerting/action-types.asciidoc

@@ -41,16 +41,19 @@ see https://www.elastic.co/subscriptions[the subscription page].
 
 [float]
 [[create-connectors]]
-=== Connectors
+=== Preconfigured connectors and action types
 
 You can create connectors for actions in <<managing-alerts-and-actions, Alerts and Actions>> or via the action API.
 For out-of-the-box and standardized connectors, you can <<pre-configured-connectors, preconfigure connectors>>
 before {kib} starts.
 
+Action type with only preconfigured connectors could be specified as a <<pre-configured-action-types, preconfigured action type>>.
+
 include::action-types/email.asciidoc[]
 include::action-types/index.asciidoc[]
 include::action-types/pagerduty.asciidoc[]
 include::action-types/server-log.asciidoc[]
 include::action-types/slack.asciidoc[]
 include::action-types/webhook.asciidoc[]
 include::pre-configured-connectors.asciidoc[]
+include::pre-configured-action-types.asciidoc[]

docs/user/alerting/pre-configured-action-types.asciidoc

@@ -0,0 +1,61 @@
+[role="xpack"]
+[[pre-configured-action-types]]
+
+== Preconfigured action types
+
+A preconfigure an action type has all the information it needs prior to startup.
+A preconfigured action type offers the following capabilities:
+
+- Requires no setup. Configuration and credentials needed to execute an
+action are predefined.
+- Has only <<pre-configured-connectors, preconfigured connectors>>.
+- Connectors of the preconfigured action type cannot be edited or deleted.
+
+[float]
+[[preconfigured-action-type-example]]
+=== Creating a preconfigured action
+
+In the `kibana.yml` file:
+
+. Exclude the action type from `xpack.actions.enabledActionTypes`.
+. Add all its connectors.
+
+The following example shows a valid configuration of preconfigured action type with one out-of-the box connector.
+
+```js
+  xpack.actions.enabledActionTypes: ['.slack', '.email', '.index'] <1>
+  xpack.actions.preconfigured:                                     <2>
+    - id: 'my-server-log'
+      actionTypeId: .server-log
+      name: 'Server log #xyz'
+```
+
+<1> `enabledActionTypes` should exclude preconfigured action type to prevent creating and deleting connectors.
+<2> `preconfigured` is the setting for defining the list of available connectors for the preconfigured action type.
+
+[float]
+[[pre-configured-action-type-alert-form]]
+=== Attaching a preconfigured action to an alert
+
+To attach an action to an alert,
+select from a list of available action types, and
+then select the *Server log* type. This action type was configured previously.
+
+[role="screenshot"]
+image::images/pre-configured-action-type-alert-form.png[Create alert with selected Server log action type]
+
+[float]
+[[managing-pre-configured-action-types]]
+=== Managing preconfigured actions
+
+Connectors with preconfigured actions appear in the connector list, regardless of which space the user is in.
+They are tagged as “preconfigured” and cannot be deleted.
+
+[role="screenshot"]
+image::images/pre-configured-action-type-managing.png[Connectors managing tab with pre-cofigured]
+
+Clicking *Create connector* shows the list of available action types.
+Preconfigured action types are not included because you can't create a connector with a preconfigured action type.
+
+[role="screenshot"]
+image::images/pre-configured-action-type-select-type.png[Pre-configured connector create menu]