Create the Investigate plugin (naming TBD). Part of
https://github.com/elastic/kibana/pull/183293, splitting up the work in
several PRs.
The investigate plugin is mostly a registry to allow plugins to register
their widgets without creating dependency issues.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/3331
Given the needs described in the linked issue about having a centralized
and async way to consume field metadata across Kibana, this work focuses
on providing server/client services to consume field metadata on demand
from static ECS definition and integration manifests, with the chance to
extend further the possible resolution sources.
3b2d9027-5c29-4081-ab17-1b43618c62a7
## 💡 Reviewers hints
This PR got quite long as it involves and touches different parts of the
codebase, so I'll break down the interesting parts for an easier review.
More details, code examples and mechanics description can be found in
the README file for the plugin.
### `@kbn/fields-metadata-plugin`
To avoid bundling and consuming the whole ECS static definition
client-side, a new plugin `@kbn/fields-metadata-plugin` is created to
expose the server/client services which enable retrieving only the
fields needed on a use-case basis.
### FieldsMetadataService server side
A `FieldsMetadataService` is instantiated on the plugin setup/start
server lifecycle, exposing a client to consume the fields and setup
tools for registering external dependencies.
The start contract exposes a `FieldsMetadataClient` instance. With this,
any application in Kibana can query for some fields using the available
methods, currently:
- `FieldsMetadataClient.prototype.getByName()`: retrieves a single
`FieldMetadata` instance.
- `FieldsMetadataClient.prototype.find()`: retrieves a record of
matching `FieldMetadata` instances.
`FieldsMetadataClient` is instantiated with the source repositories
dependencies. They act as encapsulated sources which are responsible for
fetching fields from their related source. Currently, there are 2 field
repository sources used in the resolution step, but we can use this
concept to extend the resolution step in future with more sources (LLM,
OTel, ...).
The currently used sources are:
- `EcsFieldsRepository`: allows fetching static ECS field metadata.
- `IntegrationFieldsRepository`: allows fetching fields from an
integration package from EPR, where the fields metadata are stored. To
correctly consume these fields, the `fleet` plugin must be enabled,
otherwise, the service won't be able to access the registered fields
extractor implemented with the fleet services.
As this service performs a more expensive retrieval process than the
`EcsFieldsRepository` constant complexity access, a caching layer is
applied to the retrieved results from the external source to minimize
latency.
### Fields metadata API
To expose this service to the client, a first API endpoint is created to
find field metadata and filter the results to minimize the served
payload.
- `GET /internal/fields_metadata/find` supports some initial query
parameters to narrow the fields' search.
### FieldsMetadataService client side
As we have a server-side `FieldsMetadataService`, we need a client
counterpart to consume the exposed API safely and go through the
validation steps.
The client `FieldsMetadataService` works similarly to the server-side
one, exposing a client which is returned by the public start contract of
the plugin, allowing any other to directly use fields metadata
client-side.
This client would work well with existing state management solutions, as
it's not decoupled from any library.
### useFieldsMetadata
For simpler use cases where we need a quick and easy way to consume
fields metadata client-side, the plugin start contract also exposes a
`useFieldsMetadata` react custom hook, which is pre-created accessing
the FieldsMetadataService client described above. It is important to
retrieve the hook from the start contract of this plugin, as it already
gets all the required dependencies injected minimizing the effort on the
consumer side.
The `UnifiedDocViewer` plugin changes exemplify how we can use this hook
to access and filter fields' metadata quickly.
### `registerIntegrationFieldsExtractor` (@elastic/fleet)
Getting fields from an integration dataset is more complex than
accessing a static dictionary of ECS fields, and to achieve that we need
access to the PackageService implemented by the fleet team.
To get access to the package, maintain a proper separation of concerns
and avoid a direct dependency on the fleet plugin, some actions were
taken:
- the `PackageService.prototype.getPackageFieldsMetadata()` method is
implemented to keep the knowledge about retrieving package details on
this service instead of mixing it on parallel services.
- a fleet `registerIntegrationFieldsExtractor` service is created and
used during the fleet plugin setup to register a callback that accesses
the service as an internal user and retrieves the fields by the given
parameters.
- the fields metadata plugin returns a
`registerIntegrationFieldsExtractor` function from its server setup so
that we can use it to register the above-mentioned callback that
retrieves fields from an integration.
This inverts the dependency between `fields_metadata` and `fleet`
plugins so that the `fields_metadata` plugin keeps zero dependencies on
external apps.
## Adoption
We currently have places where the `@elastic/ecs` package is directly
accessed and where we might be able to refactor the codebase to consume
this service.
**[EcsFlat usages in
Kibana](https://github.com/search?q=repo%3Aelastic%2Fkibana%20EcsFlat&type=code)**
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Implements support for [Langtrace](https://langtrace.ai/) tracing, in
order for us to more easily inspect LLM requests/responses. Previously
this depended on Kibana trace logs which are verbose and somewhat
ephemeral.
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Upgrading intl packages from v2 to v6
### Packages upgrade:
- [x] Add @formatJS packages
- [x] `react-intl` Upgraded
- [x] `intl-messageformat` Upgraded
- [x] `intl-format-cache` removed
- [x] `intl-relativeformat` removed
- [x] `intl-messageformat-parser` removed
### Todo list:
- [x] Refactor HTML tags
- [x] Refactor Upgrade tags
- [x] Refactor `kbn-i18n`
- [x] Refactor `kbn-i18n-react`
- [x] Refactor `FormattedRelative` to `FormattedRelativeTime`
- [x] Refactor polyfills
- [x] Refactor IntlShape types
- [x] Rewrite Providers
- [x] Rewrite tests using i18n
- [x] Removed current pseudolocale implementation (tracker:
https://github.com/elastic/kibana/issues/180244)
- [x] Fix jest tests using rendered `Provider`
- [x] Remove no longer valid i18n packages documentation (tracker:
https://github.com/elastic/kibana/issues/180259)
Closes https://github.com/elastic/kibana/issues/178968
Closes https://github.com/elastic/kibana/issues/38642
## Notes to code reviewers
For team other than the core team, please review your plugins code
changes by filtering files by codeowners.
### Test Snapshot updates
Most of the changes are refactors of renamed functions and changed ICU
syntax.
The main updates are snapshot changes where `FormattedMessage` is now
memoized so snapshots capturing the html tree needed to be updated to
use `<Memo(MemoizedFormattedMessage)` instead of `<FormattedMessage`
### ICU now supports HTML tags:
before:
```
<FormattedMessage
defaultMessage="To buy a shoe, { link } and { cta }"
values={{
link: (
<a class="external_link" target="_blank" href="https://www.shoe.com/">
visit our website
</a>
),
cta: <strong class="important">eat a shoe</strong>,
}}
/>
```
after:
```
<FormattedMessage
defaultMessage="To buy a shoe, <a>visit our website</a> and <cta>eat a shoe</cta>"
values={{
a: msg => (
<a class="external_link" target="_blank" href="https://www.shoe.com/">
{msg}
</a>
),
cta: msg => <strong class="important">{msg}</strong>,
}}
/>
```
### Escape character to prevent ICU parsing changed from double slashes
to single quotes:
before: `\\{escaped\\}`
after: `'{escaped}'`
### No need for Intl Shape
the new packages under formatJS are written in typescript and come with
types support out of the box so no need to set types when using i18n.
Renamed `InjectedIntlProps` with `WrappedComponentProps`.
Removed `prop-types` and `intlShape` in favor of `IntlShape`.
### FormattedRelative has been renamed to FormattedRelativeTime and its
API has changed significantly. See
[FormattedRelativeTime](https://formatjs.io/docs/react-intl/upgrade-guide-3x#formattedrelativetime)
for more details.
### All tags specified must have corresponding values and will throw
error if it's missing
All tags are now parsed and expected to be formatted properly (all
opened tags must be closed).
To skip this check you can use the `ignoreTag: true` property
```
i18n.translate('xpack.apm.agentConfig.captureJmxMetrics.description', {
defaultMessage: 'This is not an HTML tag <JMX object name pattern>' +
ignoreTag: true,
}),
```
**When do I use ignore tags?**
If your message has HTML tags, it is preferred not to ignore the Tag to
have some string verification that the html tags you are adding are
properly formatted and closed.
If it the text between brackets is not an HTML tag and it is just a
fomat preference then using `ignoreTag` makes sense.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Close https://github.com/elastic/kibana/issues/181992
## Summary
First iteration of a CLI to capture an OAS snapshot.
## How to test
Run `node ./scripts/capture_oas_snapshot.js --update --include-path
/api/status` and see result in `oas_docs/bundle.json`.
If you have the [bump CLI](https://www.npmjs.com/package/bump-cli)
installed you can preview the hosted output with `bump preview
./oas_docs/bundle.json`
## Notes
* Added ability to filter by `version`, `access` (public/internal) and
excluding paths explicitly to the OAS generation lib
* Follows the same general pattern as our other "capture" CLIs like
`packages/kbn-check-mappings-update-cli`
* Result includes only `/api/status` for now, waiting for other paths to
add missing parts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Relates to https://github.com/elastic/kibana/issues/183406.
## 📝 Summary
This PR creates a new plugin `data_quality` in order to register dataset
quality as a Stack management page under data section. For now there is
no reference to this new page in the sideNav in stateful or serverless.
In order to navigate to this new page you can use the url
`/app/management/data/data_quality`
Changes included in this PR:
- New plugin created
- Plugin registered in stack management, data section
- Dataset quality plugin is instantiated and the state is in sync with
URL
- Removed references to dataset quality in Logs explorer
## 🎥 Demo
501c9c47-4a1b-4f91-9be6-d022a821e88e
## 🙅🏼 Missing
- Dataset quality locator
- There are still references to logs explorer (table and flyout) that
will be handled in a follow up PR.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
It fixes#179633
Observability created a Comparator type/enum, when ResponseOps is
already exporting one and other rules using it.
The only difference is the wording of not in between [I put the two
types side by side to compare]
Currently, we import the one in triggers-actions-ui-plugin , and then
update the not in between to match our Comparator.
### Comparing the two enums:
## For reviewers 🧪
- Everything should work as expected: Alert flyout, Alert reason
message, Rule creation flyout, etc.
- I kept the `outside` comparator (replaced by `NOT BETWEEN`) for
backward compatibility
## Summary
As agreed in the recent ResponseOps/Security/Observability meeting, the
ResponseOps team will take ownership of the alerts grouping package
(formerly `@kbn/securitysolution-grouping`) in order to provide a
solution-agnostic API surface for future usages in Observability and
Stack rules.
This PR implements this transfer, while also renaming the package to
`@kbn/grouping` to reflect the change in scope.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This is a "proof of concept" for generating entity-centric indices for
the OAM. This exposes an API (`/api/entities`) for creating "asset
definitions" (`EntityDefinition`) that manages a transform and ingest
pipeline to produce documents into an index which could be used to
create a search experience or lookups for different services.
### Features
- Data schema agnostic, works with known schemas OR custom logs
- Supports defining multiple `identityFields` along with an
`identityTemplate` for formatting the `asset.id`
- Supports optional `identityFields` using `{ "field": "path-to-field",
"optional": true }` definition instead of a `string`.
- Supports defining key `metrics` with equations which are compatible
with the SLO product
- Supports adding `metadata` fields which will include multiple values.
- Supports `metadata` fields can be re-mapped to a new destination path
using `{ "source": "path-to-source-field", "limit": 1000, "destination":
"path-to-destination-in-output" }` definition instead of a `string`
- Supports adding `staticFields` which can also use template variables
- Support fine grain control over the frequency and sync settings for
the underlying transform
- Installs the index template components and index template settings for
the destination index
- Allow the user to configure the index patterns and timestamp field
along with the lookback
- The documents for each definition will be stored in their own index
(`.entities-observability.summary-v1.{defintion.id}`)
### Notes
- We are currently considering adding a historical index which will
track changes to the assets over time. If we choose to do this, the
summary index would remain the same but we'd add a second transform with
a group_by on the `definition.timestampField` and break the indices into
monthly indexes (configurable in the settings).
- We are looking into ways to add `firstSeenTimestamp`, this is a
difficult due to scaling issue. Essentially, we would need to find the
`minimum` timestamp for each entity which could be extremely costly on a
large datasets.
- There is nothing stopping you from creating an asset definition that
uses the `.entities-observability.summary-v1.*` index pattern to create
summaries of summaries... it can be very "meta".
### API
- `POST /api/entities/definition` - Creates a new asset definition and
starts the indexing. See examples below.
- `DELETE /api/entities/definition/{id}` - Deletes the asset definition
along with cleaning up the transform, ingest pipeline, and deletes the
destination index.
- `POST /api/entities/definition/{id}/_reset` - Resets the transform,
ingest pipeline, and destination index. This is useful for upgrading
asset definitions to new features.
## Example Definitions and Output
Here is a definition for creating services for each of the custom log
sources in the `fake_stack` dataset from `x-pack/packages/data-forge`.
```JSON
POST kbn:/api/entities/definition
{
"id": "admin-console-logs-service",
"name": "Services for Admin Console",
"type": "service",
"indexPatterns": ["kbn-data-forge-fake_stack.*"],
"timestampField": "@timestamp",
"lookback": "5m",
"identityFields": ["log.logger"],
"identityTemplate": "{{log.logger}}",
"metadata": [
"tags",
"host.name"
],
"metrics": [
{
"name": "logRate",
"equation": "A / 5",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "log.level: *"
}
]
},
{
"name": "errorRate",
"equation": "A / 5",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "log.level: \"ERROR\""
}
]
}
]
}
```
Which produces:
```JSON
{
"host": {
"name": [
"admin-console.prod.020",
"admin-console.prod.010",
"admin-console.prod.011",
"admin-console.prod.001",
"admin-console.prod.012",
"admin-console.prod.002",
"admin-console.prod.013",
"admin-console.prod.003",
"admin-console.prod.014",
"admin-console.prod.004",
"admin-console.prod.015",
"admin-console.prod.016",
"admin-console.prod.005",
"admin-console.prod.017",
"admin-console.prod.006",
"admin-console.prod.018",
"admin-console.prod.007",
"admin-console.prod.019",
"admin-console.prod.008",
"admin-console.prod.009"
]
},
"entity": {
"latestTimestamp": "2024-05-10T22:04:51.481Z",
"metric": {
"logRate": 37.4,
"errorRate": 1
},
"identity": {
"log": {
"logger": "admin-console"
}
},
"id": "admin-console",
"indexPatterns": [
"kbn-data-forge-fake_stack.*"
],
"definitionId": "admin-console-logs-service"
},
"event": {
"ingested": "2024-05-10T22:05:51.955691Z"
},
"tags": [
"infra:admin-console"
]
}
```
Here is an example of a definition for APM Services:
```JSON
POST kbn:/api/entities/definition
{
"id": "apm-services",
"name": "Services for APM",
"type": "service",
"indexPatterns": ["logs-*", "metrics-*"],
"timestampField": "@timestamp",
"lookback": "5m",
"identityFields": ["service.name", "service.environment"],
"identityTemplate": "{{service.name}}:{{service.environment}}",
"metadata": [
"tags",
"host.name"
],
"metrics": [
{
"name": "latency",
"equation": "A",
"metrics": [
{
"name": "A",
"aggregation": "avg",
"field": "transaction.duration.histogram"
}
]
},
{
"name": "throughput",
"equation": "A / 5",
"metrics": [
{
"name": "A",
"aggregation": "doc_count"
}
]
},
{
"name": "failedTransRate",
"equation": "A / B",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "event.outcome: \"failure\""
},
{
"name": "B",
"aggregation": "doc_count",
"filter": "event.outcome: *"
}
]
}
]
}
```
Which produces:
```JSON
{
"host": {
"name": [
"simianhacker's-macbook-pro"
]
},
"entity": {
"latestTimestamp": "2024-05-10T21:38:22.513Z",
"metric": {
"latency": 615276.8812785388,
"throughput": 50.6,
"failedTransRate": 0.0091324200913242
},
"identity": {
"service": {
"environment": "development",
"name": "admin-console"
}
},
"id": "admin-console:development",
"indexPatterns": [
"logs-*",
"metrics-*"
],
"definitionId": "apm-services"
},
"event": {
"ingested": "2024-05-10T21:39:33.636225Z"
},
"tags": [
"_geoip_database_unavailable_GeoLite2-City.mmdb"
]
}
```
### Getting Started
The easiest way to get started is to use the`kbn-data-forge` config
below. Save this YAML to `~/Desktop/fake_stack.yaml` then run `node
x-pack/scripts/data_forge.js --config ~/Desktop/fake_stack.yaml`. Then
create a definition using the first example above.
```YAML
---
elasticsearch:
installKibanaUser: false
kibana:
installAssets: true
host: "http://localhost:5601/kibana"
indexing:
dataset: "fake_stack"
eventsPerCycle: 50
reduceWeekendTrafficBy: 0.5
schedule:
# Start with good events
- template: "good"
start: "now-1d"
end: "now-20m"
eventsPerCycle: 50
randomness: 0.8
- template: "bad"
start: "now-20m"
end: "now-10m"
eventsPerCycle: 50
randomness: 0.8
- template: "good"
start: "now-10m"
end: false
eventsPerCycle: 50
randomness: 0.8
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/7104
Update supertest, superagent, and the corresponding type package, to
their latest version.
(of course, types had some signature changes and we're massively using
supertest in all our FTR suites so the whole Kibana multiverse has to
review it)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes: https://github.com/elastic/kibana/issues/182391
## Framework changes
- Utils to construct basic header from username and password: [`fad6bde`
(#183162)](fad6bde6af),
[`b10d103`
(#183162)](b10d103bd9)
- Automatically convert `auth` to basic auth header in the sub-actions
framework: [`ee27353`
(#183162)](ee27353051)
- Automatically convert `auth` to basic auth header in axios utils:
[`94753a7`
(#183162)](94753a7342)
## Jira
Commit: [`c366163`
(#183162)](c366163486)
## All ServiceNow connectors
Commit: [`4324d93`
(#183162)](4324d931f7)
## IBM Resilient
IBM Resilient already uses the basic auth headers. PR
https://github.com/elastic/kibana/pull/180561 added this functionality.
The connector was manually tested when reviewing the PR.
In [`7d9edab`
(#183162)](7d9edabd6e)
I updated the connector to use the new util function.
## Webhook
Commit: [`1a62c77`
(#183162)](1a62c77d46)
## Cases webhook
Commit: [`104f881`
(#183162)](104f881251)
## xMatters
Commit: [`ea7be2b`
(#183162)](ea7be2bbee)
## Connectors that do not use the `axios` `auth` property
- D3Security
- Email
- Microsoft Teams
- OpenAI
- Opsgenie
- PagerDuty
- Sentinel One
- Slack
- Slack API
- Swimlane
- Tines
- Torq
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Connectors not working correctly | Low | High | Unit test and manual
testing of all connectors affected |
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana/issues/182390
### To test
You can test all aspects of the script by first making some changes to
`packages/kbn-esql-validation-autocomplete/src/validation/validation.test.ts`
- delete several tests from an existing function describe block ("block
1"—except don't choose "date_diff" since it has a bunch of custom tests)
- delete another function describe block completely ("block 2")
- change the expected result of several of the tests in a third function
describe block ("block 3")
Then, run `yarn maketests` from within
`packages/kbn-esql-validation-autocomplete`
**Expected result**
- Block 1 should have the deleted tests restored
- Block 2 should be restored entirely (though it may be moved in the
tests file)
- Block 3 should be untouched
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Quarterly update for puppeteer, the following change set updates
puppeteer to version `22.8.1`.
The chromium version required for this version of puppeteer is
`124.0.6367.201` from revision `1274542`, as such the chromium binary
included for windows and darwin platforms either match or were the
closest revision to the expectation. The linux headless binary was built
from commit `46cf136d27d50afd9c618d164a3b95b3b62d0027` of the same
revision.
### Checklist
<!--Delete any items that are not applicable to this PR. -->
<!--
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials -->
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
<!--
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
-->
### How to verify headless build on linux
- clone the following repo
https://github.com/tsullivan/kibana-dev-docker
- pull this particular PR
- follow the steps outlined in the repo, replacing any occurrence of
`kibana-8.13.0-SNAPSHOT-linux-aarch64.tar.gz` from the repo above's step
with the output of running build on this changeset.
- before running step 4, modify the `kibana.yml` file from the
`kibana-dev-docker` repo and include the following so we might be able
to verify the version of chromium running;
```yaml
logging.loggers:
- name: plugins.reporting
level: debug
```
- complete the steps outlined in the README, you'll have a linux distro
of kibana running on port `5601`
- Attempt creating exports of PDF and PNG reports, in dashboard, canvas,
and visualizations, on report creation attempt we would see a log output
that prints out the chromium version similar to this;
<img width="1581" alt="Screenshot 2024-05-14 at 10 27 52"
src="a13de1a1-c77e-44d9-bf74-7417b7d6cfd3">
## Summary
Moved the TryInConsoleButton from the search api panels package to its
own package. This should make it easier to import and encourage usage in
more parts of Kibana even outside of search.
## Summary
Something to get us started on the AST fun. At least until we contribute
ES|QL support to https://github.com/fkling/astexplorer :)
82c482b7-cd61-4440-b723-84f863c1b596
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`v94.2.1-backport.0` ⏩ `v94.3.0`
_[Questions? Please see our Kibana upgrade
FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)_
---
## [`v94.3.0`](https://github.com/elastic/eui/releases/v94.3.0)
- Updated `launch` glyph for `EuiIcon`
([#7670](https://github.com/elastic/eui/pull/7670))
- Updated `EuiComboBox`'s `options` to support including tooltip details
for selectable options. Use `toolTipContent` to render tooltip
information, and `toolTipProps` to optionally customize the tooltip
rendering behavior ([#7700](https://github.com/elastic/eui/pull/7700))
- Updated the following existing glyphs in `EuiIcon`:
([#7727](https://github.com/elastic/eui/pull/7727))
- `error` (now an outlined version instead of filled)
- `tokenMetricCounter`
- `tokenMetricGauge`
- Added the following new glyphs to `EuiIcon`:
([#7727](https://github.com/elastic/eui/pull/7727))
- `tokenDimension`
- `clickLeft`
- `clickRight`
- `clockCounter`
- `errorFilled` (the previous `error` glyph design)
- `warningFilled`
**Bug fixes**
- Fixed a visual layout bug for `EuiComboBox` with `isLoading` in mobile
views ([#7700](https://github.com/elastic/eui/pull/7700))
- Fixed missing styles on header cells of `EuiDataGrid` that prevented
content text alignment styles to apply
([#7720](https://github.com/elastic/eui/pull/7720))
- Fixed `EuiFlexGroup` and `EuiFlexItem` `ref` prop typing to support
refs of the same type as the passed `component` type and allow
`displayName` to be defined for easy component naming when using
component wrappers like `styled()`
([#7724](https://github.com/elastic/eui/pull/7724))
---
Most of the code changes you'll see in this PR are caused by the recent
EuiFlex* changes making it generic. This, unfortunately, is something
that `styled()` doesn't always like. I replaced the failing usages of
`styled(EuiFlexGroup)` and `styled(EuiFlexItem)` to use `component` and
other native EuiFlex* props, resulting in the same output but being
better typed.
We plan to add more props to EuiFlex* components giving developers
control over properties like `flex-grow` and `flex-shring`, and reducing
the need for writing any custom CSS when using these components. This
should reduce the number of `styled()` wrappers needed even further
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: https://github.com/elastic/security-team/issues/8630
## Summary
The new version of the library implements broader support for
accessibility (a11y) and fixes the issue described in
https://github.com/elastic/security-team/issues/8630. **This library is
only used in one place in Kibana.**
### What was changed?:
1. Versions updated:
|Lib | From | To |
|--| -- | -- |
`@dnd-kit/core`| `^3.1.1`, | `^6.1.0`,
`@dnd-kit/sortable`| `^4.0.0`-|`^8.0.0`
`@dnd-kit/utilities`| `^2.0.0`, | `^3.2.2`
2. The following core was replaced in accordance with the changelog
```
layoutMeasuring={{
strategy: LayoutMeasuringStrategy.Always,
}}
```
->
```
measuring={{
droppable: {
strategy: MeasuringStrategy.Always,
},
}}
```
## Notes
During testing, an unrelated issue was discovered:
https://github.com/elastic/kibana/issues/182961.
## Summary
Migrates CLI tasks from `listr` to `listr2`. The former hasn't been
updated in a long time, and the community has moved on to `listr2`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
This work is just the extraction of a utility hook implemented in the
`infra` plugin for re-usability, as there are some scenarios where it
becomes handy in the logs explorer plugin too.
For improved reusability in future, I extracted the useBoolean hook into
a react-hooks package, where additional stateful utility hooks can go in
future.
This also replaces the current usage of the hook in the `infra` plugin
and is used to refactor part of the logs_explorer top nav.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
