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">
part of https://github.com/elastic/observability-dev/issues/3269
#### Time to First Meaningful Paint (TTFMP)
Measures the time from the start of navigation to the point at which the
most meaningful element appears on the screen. TTFMP is instrumented
differently on each page as the most meaningful element varies from page
to page.
example:
```
event_type : "performance_metric" and eventName: "kibana:plugin_render_time"
```
#### Usage
To instrument TTFMP you need to `PerfomanceContextProvider` at the root
at the app and run `onPageReady` function once meaningful data are
fetched . The meaningful data can be one or more
```
import { usePerformanceContext } from '@kbn/ebt-tools';
const { onPageReady } = usePerformanceContext();
```
#### Current instrumentation
Based on telemetry, I instrumented the TTFMP for most viewed pages in
apm and infra:
1. /services
2. /traces
3. /service-map
4. /hosts
5. infra /inventory
All pages except hosts have one component so the page ready once the
data is loaded for the component. For hosts I set it when the hosts list
table and the hosts number is loaded.
#### Telemetry
Example dashboard of the metrics I sent from my local setup
-
[Dashboard](f240fff6-fac9-491b-81d1-ac39006c5c94?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:now-7d,to:now)))
## Updates for reviewers
Previously the PR was checking both the component AND the time to first
meaningful paint. We decided to focus on the time to first meaningful
paint
### Notes
TTFMP is subject to change for each page based on what we're going to
define as meaningful
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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>
## Summary
Revives this https://github.com/elastic/kibana/pull/181969
To do so, I had to create a new package `search-types` and move the
types I need there.
The Discovery team can take it from here.
Note: It also does a cleanup on the types I move, some of them were
declared twice.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes#181528Closes#181976
**N.B.** This work was initially reviewed on a separate PR at
https://github.com/tonyghiani/kibana/pull/1.
This implementation aims to have a stateful layer that allows the
management of dependencies between Discover and other plugins, reducing
the need for a direct dependency.
Although the initial thought was to have a plugin to register features
for Discover, there might be other cases in future where we need to
prevent cyclic dependencies.
With this in mind, I created the plugin as a more generic solution to
hold stateful logic as a communication layer for Discover <-> Plugins.
## Discover Shared
Based on some recurring naming in the Kibana codebase, `discover_shared`
felt like the right place for owning these dependencies and exposing
Discover functionalities to the external world.
It is initially pretty simple and only exposes a registry for the
Discover features, but might be a good place to implement other upcoming
concepts related to Discover.
Also, this plugin should ideally never depend on other solution plugins
and keep its dependencies to a bare minimum of packages and core/data
services.
```mermaid
flowchart TD
A(Discover) -- Get --> E[DiscoverShared]
B(Logs Explorer) -- Set --> E[DiscoverShared]
C(Security) -- Set --> E[DiscoverShared]
D(Any app) -- Set --> E[DiscoverShared]
```
## DiscoverFeaturesService
This service initializes and exposes a strictly typed registry to allow
consumer apps to register additional features and Discover and retrieve
them.
The **README** file explains a real use case of when we'd need to use it
and how to do that step-by-step.
Although it introduces a more nested folder structure, I decided to
implement the service as a client-service and expose it through the
plugin lifecycle methods to provide the necessary flexibility we might
need:
- We don't know yet if any of the features we register will be done on
the setup/start steps, so having the registry available in both places
opens the door to any case we face.
- The service is client-only on purpose. My opinion is that if we ever
need to register features such as server services or anything else, it
should be scoped to a similar service dedicated for the server lifecycle
and its environment.
It should never be possible to register the ObsAIAssistant
presentational component from the server, as it should not be permitted
to register a server service in the client registry.
A server DiscoverFeaturesService is not required yet for any feature, so
I left it out to avoid overcomplicating the implementation.
## FeaturesRegistry
To have a strictly typed utility that suggests the available features on
a registry and adheres to a base contract, the registry exposed on the
DiscoverFeaturesService is an instance of the `FeaturesRegistry` class,
which implements the registration/retrieval logic such that:
- If a feature is already registered, is not possible to override it and
an error is thrown to notify the user of the collision.
- In case we need to react to registry changes, is possible to subscribe
to the registry or obtain it as an observable for more complex
scenarios.
The FeaturesRegistry already takes care of the required logic for the
registry, so that `DiscoverFeaturesService`is left with the
responsibility of instantiating/exposing an instance and provide the set
of allowed features.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
## Summary
Bump `ejs` from `3.1.8` to `3.1.10`. While looking at other packages
that depend on `ejs` noticed `apidoc-markdown` that is only used by ML
team, so assigned ownership in Rennovate as well (cc @elastic/ml-ui).
```shell
npm ls ejs
kibana@8.15.0 /kibana
├─┬ apidoc-markdown@7.3.2
│ └── ejs@3.1.10 deduped
└── ejs@3.1.10
```
**Resolves: https://github.com/elastic/kibana/issues/180121**
**Resolves: https://github.com/elastic/kibana/issues/180122**
**Resolves: https://github.com/elastic/kibana/issues/180124**
## Summary
As part of the preparatory changes for the work in Milestone 3, we want
to add the new `rule_source` field to the API schema.
- Added `rule_source` as an **optional** property to `RuleResponse`, by
introducing it as an optional property in the `ResponseFields` schema.
- For now, all endpoints should return `undefined` for the `rule_source`
field.
- Added `rule_source` as an **optional** property to `RuleToImport`,
which defines the schema of required and accepted fields when importing
a rule.
- For now, the new `rule_source` field should be ignored in the endpoint
logic.
- Added the `ruleSource` field to the `BaseRuleParams` schema, as an
optional field.
- Implemented a Zod transformation from `snake_case` to `camelCase` for
object keys to reduce code duplication.
Create an empty assets data access plugin so we can start registering
the services(APIs) that will be used to fetch assets type documents.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Removing jest-axe and supporting code from Kibana because this library
(not regularly updated anymore and used only in one test file) is
blocking me from updating axe-core.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Changes
1. adds `hidePanelChrome` parameter to `ReactEmbeddableRenderer`. When
true, embeddable is rendered without `PresentationPanel` wrapper
2. Removes `embeddable-explorer` plugin
3. Moves Embeddable developer example into embeddable_examples plugin
4. Creates new examples that demonstrate how to use
`ReactEmbeddableRenderer`
<img width="600" alt="Screenshot 2024-04-23 at 5 19 18 PM"
src="5167a2a4-1968-42e6-92f7-4577c9cda3c6">
Follow-up work to narrow scope of this PR
1. add key concepts to embeddable overview
2. add "Register new embeddable type" tab that details how to create a
new embeddable and shows how you can add embeddable examples to
dashboard
3. group embeddable examples into a single item in "Add panel" menu - to
show best practices of how to keep menu clean
4. remove class based example embeddables
### Test instructions
1. start kibana with `yarn start --run-examples`
5. Open kibana menu and click "Developer examples"
6. Click "Embeddables" card and run examples
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>