## Summary
This PR reverts https://github.com/elastic/kibana/pull/189633.
### Background
PR : https://github.com/elastic/kibana/pull/189633 had created a package
`security_solution_common` so that security components can be easily
used in Discover plugins.
But because of recent direction change, I have decided to revert that
change which mainly moved `flyout` code to the
`security_solution_common` package.
Most of the changes that you will see will be path changes replacing
`security_solution_common`.
## TL;DR
`security_solution_common` is being removed as the reason it was created
does not exists any more.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
At the moment, all inference API related types and utilities
(`chatComplete`, `output` and more) are living inside the `inference`
plugin's common folder.
This is somewhat problematic because it forces any consumers of those
types to explicitly depends on the `inference` plugin (via plugin dep or
ts ref), which could lead to any kind of cyclic dependency issues, in
addition to being overall a bad design pattern.
This also makes it more complicated that it should to try to split the
inference logic / task framework / task implementation into distinct
packages or plugins, due to some (concrete) utilities living in the
inference plugin's code.
It's also a bad experience for consumers, as it's quite difficult to
easily resolve imports they need (we're mixing internal and public
exports atm, plus not all types are exported from a single entry point,
making it very tedious to find the right path for each individual import
we need to consume the inference APIs)
This PR addresses most of those points, by introducing a new
`@kbn/inference-common` package and moving all the low level types and
utilities to it, while exposing all of them from the package's
entrypoint.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [msw](https://mswjs.io) ([source](https://togithub.com/mswjs/msw)) |
devDependencies | patch | [`^2.4.11` ->
`^2.4.12`](https://renovatebot.com/diffs/npm/msw/2.4.11/2.4.12) |
`2.5.2` (+3) |
---
### Release Notes
<details>
<summary>mswjs/msw (msw)</summary>
### [`v2.4.12`](https://togithub.com/mswjs/msw/releases/tag/v2.4.12)
[Compare
Source](https://togithub.com/mswjs/msw/compare/v2.4.11...v2.4.12)
#### v2.4.12 (2024-10-21)
##### Bug Fixes
- **node:** preserve headers instanceof when recording raw headers
([#​2321](https://togithub.com/mswjs/msw/issues/2321))
([`a58a300`](a58a300687))
[@​paoloricciuti](https://togithub.com/paoloricciuti)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNsb3VkIFNlY3VyaXR5IiwiYmFja3BvcnQ6c2tpcCIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [@elastic/charts](https://togithub.com/elastic/elastic-charts) |
dependencies | patch | [`68.0.1` ->
`68.0.2`](https://renovatebot.com/diffs/npm/@elastic%2fcharts/68.0.1/68.0.2)
|
---
### Release Notes
<details>
<summary>elastic/elastic-charts (@​elastic/charts)</summary>
###
[`v68.0.2`](https://togithub.com/elastic/elastic-charts/blob/HEAD/CHANGELOG.md#6802-2024-10-24)
[Compare
Source](https://togithub.com/elastic/elastic-charts/compare/v68.0.1...v68.0.2)
##### Bug Fixes
- **xy:** single point visibility
([#​2557](https://togithub.com/elastic/elastic-charts/issues/2557))
([e16c902](e16c902dd5))
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOlZpc3VhbGl6YXRpb25zIiwiYmFja3BvcnQ6cHJldi1taW5vciIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Implements https://github.com/elastic/kibana/issues/193450.
## Discover changes ⚠️
As part of this we need to render a basic table with the log level and
summary columns, which is technically context aware but only in the
sense we know we want it to be a logs context up front.
The "correct" solution here (or at least from recent conversations) is
to use the saved search embeddable. There is upcoming work planned to
move log stream component usages over to the saved search embeddable.
However, currently this isn't in a place to just be dropped in without
some pretty extensive work. I didn't feel comfortable doing a big push
on that work as a side effort to this work, especially with a loose (if
possible) 8.16 aim for this.
What I've done (and which isn't ideal I appreciate) is used the start
contract of the Discover plugin to export the columns / cells
pre-wrapped with the Discover services. It's not ideal in the sense of
dependencies, but technically Discover doesn't use logs shared. I
considered Discover shared but that's for registering functionality for
Discover, rather than the other way around.
Eventually we'll be able to remove this and convert over to the new
solution. I'm all ears to a better solution, but there's a big mismatch
between the needs here and dropping in something that exists currently.
Thankfully the changeset for Discover is small if we're happy to keep
this temporarily.
Edit: I've made some notes here:
https://github.com/elastic/logs-dev/issues/111#issuecomment-2411096251
Edit: New package added here:
c290819c1c
## Overview
From a high level:
- Adds a new state machine for handling "details" to show in the flyout
(document examples now, plus details and a timeline later).
- Hooks this up to a flyout expanded from the categories table.
- Provides linking to Discover to view documents from the category in
the flyout.
I've also left some comments inline.
## UI / UX
---------
Co-authored-by: Felix Stürmer <felix.stuermer@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
## Summary
Addresses https://github.com/elastic/kibana-team/issues/1175
As part of the **Sustainable Kibana Architecture** initiative, this PR
sets the foundation to start classifying plugins in isolated groups,
matching our current solutions / project types:
* It adds support for the following fields in the packages' manifests
(kibana.jsonc):
* `group?: 'search' | 'security' | 'observability' | 'platform' |
'common'`
* `visibility?: 'private' | 'shared'`
* It proposes a folder structure to automatically infer groups:
```javascript
'src/platform/plugins/shared': {
group: 'platform',
visibility: 'shared',
},
'src/platform/plugins/internal': {
group: 'platform',
visibility: 'private',
},
'x-pack/platform/plugins/shared': {
group: 'platform',
visibility: 'shared',
},
'x-pack/platform/plugins/internal': {
group: 'platform',
visibility: 'private',
},
'x-pack/solutions/observability/plugins': {
group: 'observability',
visibility: 'private',
},
'x-pack/solutions/security/plugins': {
group: 'security',
visibility: 'private',
},
'x-pack/solutions/search/plugins': {
group: 'search',
visibility: 'private',
},
```
* If a plugin is moved to one of the specific locations above, the group
and visibility in the manifest (if specified) must match those inferred
from the path.
* Plugins that are not relocated are considered: `group: 'common',
visibility: 'shared'` by default. As soon as we specify a custom
`group`, the ESLINT rules will check violations against dependencies /
dependants.
The ESLINT rules are pretty simple:
* Plugins can only depend on:
* Plugins in the same group
* OR plugins with `'shared'` visibility
* Plugins in `'observability', 'security', 'search'` groups are
mandatorily `'private'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [msw](https://mswjs.io) ([source](https://togithub.com/mswjs/msw)) |
devDependencies | patch | [`^2.4.10` ->
`^2.4.11`](https://renovatebot.com/diffs/npm/msw/2.4.11/2.4.11) |
`2.4.12` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNsb3VkIFNlY3VyaXR5IiwiYmFja3BvcnQ6c2tpcCIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [msw](https://mswjs.io) ([source](https://togithub.com/mswjs/msw)) |
devDependencies | patch | [`^2.4.9` ->
`^2.4.10`](https://renovatebot.com/diffs/npm/msw/2.4.9/2.4.10) |
`2.4.11` |
---
### Release Notes
<details>
<summary>mswjs/msw (msw)</summary>
### [`v2.4.10`](https://togithub.com/mswjs/msw/releases/tag/v2.4.10)
[Compare
Source](https://togithub.com/mswjs/msw/compare/v2.4.9...v2.4.10)
#### v2.4.10 (2024-10-11)
##### Bug Fixes
- **setupWorker:** perform worker update in the background
([#​2311](https://togithub.com/mswjs/msw/issues/2311))
([`8e40724`](8e40724cd3))
[@​kettanaito](https://togithub.com/kettanaito)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNsb3VkIFNlY3VyaXR5IiwiYmFja3BvcnQ6c2tpcCIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
---------
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [listr2](https://togithub.com/listr2/listr2) | devDependencies | patch
| [`^8.2.4` ->
`^8.2.5`](https://renovatebot.com/diffs/npm/listr2/8.2.4/8.2.5) |
---
### Release Notes
<details>
<summary>listr2/listr2 (listr2)</summary>
###
[`v8.2.5`](https://togithub.com/listr2/listr2/releases/tag/listr2%408.2.5)
[Compare
Source](https://togithub.com/listr2/listr2/compare/listr2@​8.2.4...listr2@​8.2.5)
#### listr2
[8.2.5](https://togithub.com/listr2/listr2/compare/listr2@​8.2.4...listr2@​8.2.5)
(2024-10-03)
##### Bug Fixes
- ability to use zen-observable
([bae701b](bae701bab5)),
closes [#​724](https://togithub.com/listr2/listr2/issues/724)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
closes https://github.com/elastic/kibana/issues/193992
How to open cypress dashboard locally:
```
node x-pack/plugins/observability_solution/inventory/scripts/test/e2e.js --open
```
How to run cypress tests:
```
node x-pack/plugins/observability_solution/inventory/scripts/test/e2e.js
```
How to run cypress tests multiple times:
```
node x-pack/plugins/observability_solution/inventory/scripts/test/e2e.js --server
node x-pack/plugins/observability_solution/inventory/scripts/test/e2e.js --runner --times=X
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is part of
https://github.com/elastic/kibana-team/issues/1016#issuecomment-2399310175
and needed to upgrade Kibana to React@18 in Legacy mode.
We've found a problem in `react-monaco-editor` component which is a very
thin wrapper around `monaco` where it doesn't play nicely with React@18
in legacy mode. You can read on details around the issue here
https://github.com/elastic/eui/issues/8018 where we've found a similar
issue in EUI's search bar component. The workaround we've found is to
change `useEffect` -> `useLayouEffect` where the value that is coming
from the prop is set into the model. The issue and a fix might be a bit
controversal and the component is very thin, so I decided that it might
be better to bring the fork into Kibana with only what's needed and with
a workaround.
## Summary
This PR implements virtualization when Event Renderers are enabled.
Ideally from UX pespective nothing should change but from performance
perspective, the event renderers should be scalable.
### Testing checklist
1. UX is working same as before when Event Renderers are enabled.
2. Operations such as increasing page size from `10` to `100` are not
taking as much time as before. Below operations can be used to test.
a. Closing / Opening Timeline
b. Changes `Rows per page`
c. Changes tabs from query to any other and back.
### Before
In below video, you will notice how long it took to change `pageSize` to
100 and all 100 rows are rendered at once.
https://github.com/user-attachments/assets/106669c9-bda8-4b7d-af3f-b64824bde397
### After
https://github.com/user-attachments/assets/356d9e1f-caf1-4f88-9223-0e563939bf6b
> [!Note]
> 1. Also test in small screen. The table should be scrollable but
nothing out of ordinary.
> 2. Additionally, try to load data which has `network_flow` process so
as to create bigger and varied Event Renderers.
---------
Co-authored-by: Cee Chen <constance.chen@elastic.co>
## Summary
This change is the implementation of the `Kibana Privilege Migrations`
proposal/RFC and provides a framework that allows developers to replace
an existing feature with a new one that has the desired configuration
while teaching the platform how the privileges of the deprecated feature
can be represented by non-deprecated ones. This approach avoids
introducing breaking changes for users who still rely on the deprecated
privileges in their existing roles and any automation.
Among the use cases the framework is supposed to handle, the most common
are the following:
* Changing a feature ID from `Alpha` to `Beta`
* Splitting a feature `Alpha` into two features, `Beta` and `Gamma`
* Moving a capability between privileges within a feature (top-level or
sub-feature)
* Consolidating capabilities across independent features
## Scope
This PR includes only the core functionality proposed in the RFC and
most of the necessary guardrails (tests, early validations, etc.) to
help engineers start planning and implementing their migrations as soon
as possible. The following functionality will be added in follow-ups or
once we collect enough feedback:
* Telemetry
* Developer documentation
* UI enhancements (highlighting roles with deprecated privileges and
manual migration actions)
## Framework
The steps below use a scenario where a feature `Alpha` should be split
into two other features `Beta` and `Gamma` as an example.
### Step 1: Create new features with the desired privileges
First of all, define new feature or features with the desired
configuration as you'd do before. There are no constraints here.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
id: 'feature_beta',
name: 'Feature Beta',
privileges: {
all: {
savedObject: { all: ['saved_object_1'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1'] },
ui: ['ui_read'],
api: ['api_read'],
… omitted for brevity …
},
},
… omitted for brevity …
});
deps.features.registerKibanaFeature({
id: 'feature_gamma',
name: 'Feature Gamma',
privileges: {
all: {
savedObject: { all: ['saved_object_2'], read: [] },
ui: ['ui_all'],
// Note that Feature Gamma, unlike Features Alpha and Beta doesn't provide any API access tags
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_2'] },
ui: ['ui_read'],
// Note that Feature Gamma, unlike Features Alpha and Beta doesn't provide any API access tags
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 2: Mark existing feature as deprecated
Once a feature is marked as deprecated, it should essentially be treated
as frozen for backward compatibility reasons. Deprecated features will
no longer be available through the Kibana role management UI and will be
replaced with non-deprecated privileges.
Deprecated privileges will still be accepted if the role is created or
updated via the Kibana role management APIs to avoid disrupting existing
user automation.
To avoid breaking existing roles that reference privileges provided by
the deprecated features, Kibana will continue registering these
privileges as Elasticsearch application privileges.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
// This is a new `KibanaFeature` property available during feature registration.
deprecated: {
// User-facing justification for privilege deprecation that we can display
// to the user when we ask them to perform role migration.
notice: i18n.translate('xpack.security...', {
defaultMessage: "Feature Alpha is deprecated, refer to {link}...",
values: { link: docLinks.links.security.deprecatedFeatureAlpha },
})
},
// Feature id should stay unchanged, and it's not possible to reuse it.
id: 'feature_alpha',
name: 'Feature Alpha (DEPRECATED)',
privileges: {
all: {
savedObject: { all: ['saved_object_1', 'saved_object_2'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2'] },
ui: ['ui_read'],
api: ['api_read'],
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 3: Map deprecated feature’s privileges to the privileges of the
non-deprecated features
The important requirement for a successful migration from a deprecated
feature to a new feature or features is that it should be possible to
express **any combination** of the deprecated feature and sub-feature
privileges with the feature or sub-feature privileges of non-deprecated
features. This way, while editing a role with deprecated feature
privileges in the UI, the admin will be interacting with new privileges
as if they were creating a new role from scratch, maintaining
consistency.
The relationship between the privileges of the deprecated feature and
the privileges of the features that are supposed to replace them is
expressed with a new `replacedBy` property available on the privileges
of the deprecated feature.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
// This is a new `KibanaFeature` property available during feature registration.
deprecated: {
// User-facing justification for privilege deprecation that we can display
// to the user when we ask them to perform role migration.
notice: i18n.translate('xpack.security...', {
defaultMessage: "Feature Alpha is deprecated, refer to {link}...",
values: { link: docLinks.links.security.deprecatedFeatureAlpha },
})
},
// Feature id should stay unchanged, and it's not possible to reuse it.
id: 'feature_alpha',
name: 'Feature Alpha (DEPRECATED)',
privileges: {
all: {
savedObject: { all: ['saved_object_1', 'saved_object_2'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['all'] },
{ feature: 'feature_gamma', privileges: ['all'] },
],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2'] },
ui: ['ui_read'],
api: ['api_read'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['read'] },
{ feature: 'feature_gamma', privileges: ['read'] },
],
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 4: Adjust the code to rely only on new, non-deprecated features
Special care should be taken if the replacement privileges cannot reuse
the API access tags from the deprecated privileges and introduce new
tags that will be applied to the same API endpoints. In this case,
developers should replace the API access tags of the deprecated
privileges with the corresponding tags provided by the replacement
privileges. This is necessary because API endpoints can only be accessed
if the user privileges cover all the tags listed in the API endpoint
definition, and without these changes, existing roles referencing
deprecated privileges won’t be able to access those endpoints.
The UI capabilities are handled slightly differently because they are
always prefixed with the feature ID. When migrating to new features with
new IDs, the code that interacts with UI capabilities will be updated to
use these new feature IDs.
<details>
<summary>Click to see the code</summary>
```ts
// BEFORE deprecation/migration
// 1. Feature Alpha defition (not deprecated yet)
deps.features.registerKibanaFeature({
id: 'feature_alpha',
privileges: {
all: {
api: ['api_all'],
… omitted for brevity …
},
},
… omitted for brevity …
});
// 2. Route protected by `all` privilege of the Feature Alpha
router.post(
{ path: '/api/domain/my_api', options: { tags: ['access:api_all'] } },
async (_context, request, response) => {}
);
// AFTER deprecation/migration
// 1. Feature Alpha defition (deprecated, with updated API tags)
deps.features.registerKibanaFeature({
deprecated: …,
id: 'feature_alpha',
privileges: {
all: {
api: ['api_all_v2'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['all'] },
],
… omitted for brevity …
},
},
… omitted for brevity …
});
// 2. Feature Beta defition (new)
deps.features.registerKibanaFeature({
id: 'feature_beta',
privileges: {
all: {
api: ['api_all_v2'],
… omitted for brevity …
}
},
… omitted for brevity …
});
// 3. Route protected by `all` privilege of the Feature Alpha OR Feature Beta
router.post(
{ path: '/api/domain/my_api', options: { tags: ['access:api_all_v2'] } },
async (_context, request, response) => {}
);
----
// ❌ Old client-side code (supports only deprecated privileges)
if (capabilities.feature_alpha.ui_all) {
… omitted for brevity …
}
// ✅ New client-side code (will work for **both** new and deprecated privileges)
if (capabilities.feature_beta.ui_all) {
… omitted for brevity …
}
```
</details>
## How to test
The code introduces a set of API integration tests that are designed to
validate whether the privilege mapping between deprecated and
replacement privileges maintains backward compatibility.
You can run the test server with the following config to register a
number of [example deprecated
features](https://github.com/elastic/kibana/pull/186800/files#diff-d887981d43bbe30cda039340b906b0fa7649ba80230be4de8eda326036f10f6fR20-R49)(`x-pack/test/security_api_integration/plugins/features_provider/server/index.ts`)
and the features that replace them, to see the framework in action:
```bash
node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/features.config.ts
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`v96.1.0`⏩`v97.0.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)_
---
## [`v97.0.0`](https://github.com/elastic/eui/releases/v97.0.0)
**Breaking changes**
- EuiDataGrid's custom grid body (rendered via `renderCustomGridBody`)
no longer automatically renders the column header row or footer rows. It
instead now passes the `headerRow` and `footerRow` React elements, which
require manual rendering.
([#8028](https://github.com/elastic/eui/pull/8028))
- This change was made to allow consumers to sync header/footer rows
with their own custom virtualization libraries.
- To facilitate this, a `gridWidth` prop is now also passed to custom
grid body renderers.
**Bug fixes**
- Fixed inputs not taking the whole width when passing `fullWidth` as
`true` to EuiDatePickerRange component
([#8061](https://github.com/elastic/eui/pull/8061))
**Accessibility**
- Improved accessibility of `EuiExternalLinkIcon` by clarifying text for
Screen Reader users. ([#8065](https://github.com/elastic/eui/pull/8065))
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This actually uses the Search Assistant scope to modify the assistant's
behavior depending on the context they're in. The assistant now:
- Defaults to Observability mode
- Is a Search assistant in the Search pages
- Switches dynamically, changing available functions, prompts and
instructions based on context
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This extracts the Observability AI Assistant into a shared package so
Search and Observability can both consume it.
A few notes:
This still relies on significantly tight coupling with the Obs AI
assistant plugin, which we will want to slowly decouple over time. It
means that currently to consume this in multiple places, you need to
provide a number of plugins for useKibana. Hopefully we can get rid of
that and replace them with props eventually and make the interface a
little less plugin-dependent.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This is a re-submission of https://github.com/elastic/kibana/pull/191899, which was reverted due to
a storybook build problem. This introduces a "Logs Overview" component for use in solution UIs
behind a feature flag.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kerry Gallagher <471693+Kerry350@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
