This PR adds the auto-increase the fields limit on startup when an
alerts index reaches its limits because of the dynamic fields.
# To verify:
To be able to test this PR we need a rule type that adds dynamic fields.
I used the custom threshold rule for this:
Go to the custom threshold rule type definition and change its
alerts.mappings to:
```
mappings: {
// dynamic: true,
fieldMap: {
'kibana.alerting.grouping': {
type: 'object',
dynamic: true,
array: false,
required: false,
},
...legacyExperimentalFieldMap,
...Array(412)
.fill(0)
.reduce((acc, val, i) => {
acc[`${i + 1}`] = { type: 'keyword', array: false, required: false };
return acc;
}, {}),
},
dynamicTemplates: [
{
strings_as_keywords: {
path_match: 'kibana.alert.grouping.*',
match_mapping_type: 'string',
mapping: {
type: 'keyword',
ignore_above: 1024,
},
},
},
],
},
```
Above changes adds 412 dummy fields to the alerts index to make it close to reach its fields limit (default: 2500).
And makes everything under `kibana.alert.grouping` path to be added to the index as dynamic fields.
Then apply the below changes to the custom threshold rule executor:
```
const grouping: Record<string, string> = {};
groups?.forEach((groupObj) => (grouping[groupObj.field] = groupObj.value));
const { uuid, start } = alertsClient.report({
id: `${group}`,
actionGroup: actionGroupId,
payload: {
[ALERT_REASON]: reason,
[ALERT_EVALUATION_VALUES]: evaluationValues,
[ALERT_EVALUATION_THRESHOLD]: threshold,
[ALERT_GROUP]: groups,
// @ts-ignore
['kibana.alerting.grouping']: grouping,
...flattenAdditionalContext(additionalContext),
...getEcsGroups(groups),
},
});
```
Above changes add the selected groups under `kibana.alerting.grouping` path.
Then:
- Run ES with ` path.data=../your-local-data-path` to keep the data for the next start.
- Run Kibana
- Create a custom threshold rule that generates an alert and has at least 2 groups.
- Let the rule run.
- Go to `Stack Management` > `Index Management` and search for observability threshold index.
- Check its mappings, it should show the dummy fields you have added to the rule type and the first grouping you have selected while you were creating the rule type.
- Go to the Dev Tools and find your alert in the `.internal.alerts-observability.threshold.alerts-default-000001` index.
The other groups you have selected should be saved under `_ignored` field:
```
"_ignored": [
"kibana.alerting.grouping.host.name"
],
```
- Stop Kibana
- increase the number of dummy fields you have added to the rule type definition:
```
...Array(412) <-- make this greater than 412
.fill(0)
```
- Start kibana again.
- The new fields should be added to the mappings. Check them on `Stack Management` > `Index Management`
- Check also the index settings: `Stack Management` > `Index Management` > `.internal.alerts-observability.threshold.alerts-default-000001` > settings tab.
- `"mapping" > "total_fields" > "limit" ` should be greater than 2500
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/217433
## Summary
This PR fixes the Console output when the response body is an empty
string.
In https://github.com/elastic/kibana/pull/199975, we made Console to
display an `OK` output if the status code is 200 but response body is
`null`. Previously, `POST
/_cluster/voting_config_exclusions?node_names=node` returned `null` and
so the output was correctly set to `OK` but now the response is an empty
string and this case isn't covered correctly. In this PR, we make sure
to perform the right check at the right point so that both `null` and
empty strings are covered.
The test that covers this scenario and had failures:
7092e79157/src/platform/test/functional/apps/console/_console.ts (L258)
To run the failing test with the new Es snapshots:
```
ES_SNAPSHOT_MANIFEST="20250414-022022_f16f4ce6/manifest.json" node scripts/functional_tests_server.js --config ./src/platform/test/functional/apps/console/config.ts
```
and
```
ES_SNAPSHOT_MANIFEST="20250414-021844_4ed1a000/manifest.json" node scripts/functional_test_runner.js --config ./src/platform/test/functional/apps/console/config.ts --grep="Shows OK when status code is 200 but body is empty"
```
## Summary
This PR adds some alert actions to the AI for SOC alert summary page:
- table row action via a more actions icon button, to allow users to add
the alert to a new case, an existing case, or to apply tags to the
current alert
- a take action in the footer of the flyout, to allow the user to
perform the same actions
Table row actions:
https://github.com/user-attachments/assets/a5991ec0-a1c1-4c8f-821a-5adedd3d68a7
Flyout footer actions:
https://github.com/user-attachments/assets/f5d853d3-8b5e-47f8-ba30-33cdf440651b
### Notes
The code is extremely similar between the 2 components added in this PR.
The difference between the 2 is the type of button that is used to open
the popover.
I debated 2 others approaches, but was not happy with either:
- create a hook that would return the items and panels for cases and
tags, then use that hook to limit the amount of duplicated code in both
components. I decided against this as I hate having hooks that return
components (in this case `EuiContextMenuItems`...
- create a shared component that would do the logic and have some props
to conditionally decide how the button is being displayed. Here also, I
decided against this approach because I feel like components that allow
these sort of UI customization quickly end up hard to maintain, because
we want to change the text, then the color of the button, then the type
of icon...
If you feel strongly about the choice I made here, let me know and I'll
reconsider the approach! 😄
## How to test
This needs to be ran in Serverless:
- `yarn es serverless --projectType security`
- `yarn serverless-security --no-base-path`
You also need to enable the AI for SOC tier, by adding the following to
your `serverless.security.dev.yaml` file:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
Use one of these Serverless users:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
Then:
- generate data: `yarn test:generate:serverless-dev`
- create 4 catch all rules, each with a name of a AI for SOC integration
(`google_secops`, `microsoft_sentinel`,, `sentinel_one` and
`crowdstrike`) => to do that you'll need to temporary comment the
`serverless.security.dev.yaml` config changes as the rules page is not
accessible in AI for SOC.
- change [this
line](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/detections/hooks/alert_summary/use_fetch_integrations.ts#L73)
to `installedPackages: availablePackages` to force having some packages
installed
- change [this
line](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/detections/hooks/alert_summary/use_integrations.ts#L63)
to `r.name === p.name` to make sure there will be matches between
integrations and rules
### Checklist
- [x] 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/src/platform/packages/shared/kbn-i18n/README.md)
- [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
https://github.com/elastic/security-team/issues/11973
Closes#215534
## Summary
The Encrypted Saved Objects Key Rotation service makes use of the Saved
Objects Bulk Update API to re-encrypt objects. Bulk update supports an
optional 'namespace' parameter, per-object, defining the space to access
a specific object. This allows objects outside of the current space to
be affected in the update operation. The Key Rotation service leverages
this optional parameter for each object to ensure that the re-encryption
operation is not limited to the current space.
However, should a multi-namespace encrypted object reside in all spaces,
the only value in the object's namespaces property is the
`ALL_NAMESPACES_STRING` constant '*'. As this is not a valid single
namespace, the Bulk Update operation will skip updating the object.
PR resolves the issue by only providing a object namespace for objects
that do not reside in all spaces. Objects that reside in all spaces can
be accessed from the current space without the need for an override.
This PR also updates unit tests to account for this case.
### Testing
- [x] Set the encrypted saved objects encryption key to a known value
(either in kibana.yml or kibana.dev.yml). For example:
```
xpack.encryptedSavedObjects:
encryptionKey: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
```
- [x] Start ES & Kibana
- [x] You will need to set up a Fleet agent policy and create a
synthetics location and monitor. The UI will guide you through this when
you navigate to Observability -> Synthetics
- [x] Create a synthetics parameter, Observability -> Synthetics ->
Settings, Global Parameters tab. Use anything for a value, but be sure
to check the `Share across spaces` option.
- [x] Update the kibana config to change the encryption key, and use the
old key as a decryption-only key
```
xpack.encryptedSavedObjects:
encryptionKey: "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
keyRotation:
decryptionOnlyKeys: ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]
```
- [x] Wait for Kibana to restart
- [x] Call the key rotation HTTP API as a privileged user (I just used
the `elastic` superuser account)
`[you_kibana_endpoint]/api/encrypted_saved_objects/_rotate_key?type=synthetics-param`
- [x] Verify that 1 out of 1 objects were processed with 0 failures.
- [x] Repeat these steps from Main and note that 0 of 1 objects
succeeded, and there is 1 failure
### Release Note
Fixes an issue where the Saved Objects Rotate Encryption Key API would
not affect sharable encrypted object types that exist in all spaces.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
There were several trigger characters on our completion item provider
that weren't doing anything. This removes them!
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR attempts to simplify our Cypress tests to focus in on what
exactly we want a test to be doing. Many of our rule creation cypress
tests were testing rule creation, rule edit, rule details and more. This
results in a lot of flake and us triaging tests that often test things
other than what we're ultimately trying to answer.
I tried to simplify it so the rule specific tests simply answer - can we
create this rule type in the UI? Then there's a single test for checking
the entire flow of create rule -> rule details and check for alerts. The
FTRs should be ensuring that the rules generate alerts as expected so we
don't need to check this for every rule type in cypress.
I also moved alert suppression into it's own folder as there is a lot of
specific logic to test around that.
**Resolves: https://github.com/elastic/security-team/issues/7216**
## Summary
This PR updates the Endpoint policy callback to:
- **Install only the Elastic Defend rule if it's missing**, without
upgrading it to the latest version. Previously, the rule was both
installed and updated whenever an Endpoint policy was created, which
conflicted with rule customization. Automatic upgrades could erase
existing user customizations.
- **Avoid triggering the installation or upgrade of any other prebuilt
rules** as part of this flow. The Endpoint package policy creation
callback
([source](f7d8bc3c25/x-pack/solutions/security/plugins/security_solution/server/fleet_integration/fleet_integration.ts (L181-L187)))
previously installed and upgraded **all** prebuilt detection rules to
their target versions whenever an Endpoint policy was created.
This logic relied on the legacy rule upgrade method, which has a known
issue that causes all configured rule actions and exceptions to be lost.
By removing the upgrade logic, this PR eliminates that incorrect
behavior.
## Summary
In QAF David added a possibility to spin up MKI project with custom role
set and ready to use.
Originally FTR was using reserved name `'customRole'` for internal
Kibana role to be mapped with native custom role in the project.
Both Scout and FTR use `kbn/test` to simulate SAML authentication, but
the new framework will allow to run the tests in parallel. That said, we
need to support multiple custom role credentials (one pair per worker)
and for simplicity we decided to use the same keys:
To run your tests locally against MKI you need to add a new Cloud user
entry in `user_roles.json`:
```
"custom_role_worker_1": { "username": ..., "password": ... }, // FTR requires only the first entry
"custom_role_worker_2": { "username": ..., "password": ... },
...
```
The test change is minimal:
<img width="559" alt="image"
src="https://github.com/user-attachments/assets/572103a3-13b2-4e6c-b9d2-5e55b03ac51c"
/>
---------
Co-authored-by: Cesare de Cal <cesare.decal@elastic.co>
## Summary
This PR fixes the existing usage of the chart themes by using the
provided `useElasticChartsTheme` hook that is color mode aware and theme
adaptive (borealis/amsterdam)
Some charts where using just the Light theme version or the legacy (aka
amsterdam theme), and I've applied the hook to pick up the correct
theme.
TO REVIEWERS: Please pull down the PR and check if the actual changed
charts looks correct with the new theme configuration.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Anton Dosov <anton.dosov@elastic.co>
## Summary
Fix#70745
Enables the option to open the clickable mark links of a Vega
Visualization in a new tab.
To achieve this functionality:
- use the `usermeta.embedOptions.loader` property in the vega chart spec
to pass the `"target": "_blank"` configuration:
```javascript
"usermeta": {
"embedOptions": {
"loader": {"target": "_blank"}
}
}
```
Link opens in a new tab:
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/216808
## Summary
Instead of directly passing the `apiKey` and `userScope` (when
available) into each task type runner, we create a fake Kibana Request
with an Authorization ApiKey header in the task manager and pass that
request into the task type runner.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Currently streams doesn't allow you to delete an orphaned stream because
`getPipelineTargets` required the data stream to exist.
This PR fixes the problem by handling the case gracefully.
## Summary
Closes https://github.com/elastic/kibana/issues/206245
To test:
- enable feature flag `xpack.fleet.enableExperimental:
['enableSyncIntegrationsOnRemote']`
- Add `Custom Filestream Logs` integration and set `Ingest Pipeline` var
e.g. `filestream-pipeline1`
- Create Ingest Pipeline with the same name
- Wait a few minutes for the sync task to run, check that the ingest
pipeline appears in the sync index
- Set up a second cluster to enable CCR by following this guide:
https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/dev_docs/local_setup/remote_clusters_ccr.md
- Verify that the ingest pipeline is synced to the remote cluster
- Use a remote ES output as data output on the agent policy with the
filestream policy
- Enroll an agent to the agent policy in a multipass VM
- Verify that data is being ingested in the remote cluster to the
filestream dataset and the field in the pipeline is set
<img width="1105" alt="image"
src="https://github.com/user-attachments/assets/751b6f23-6ea7-4fbf-b6cc-fd441ca848e1"
/>
<img width="1591" alt="image"
src="https://github.com/user-attachments/assets/9ef159f3-f399-4d4e-8e57-ecdf52bf4f6f"
/>
```
GET fleet-synced-integrations/_search
{
"_index": "fleet-synced-integrations",
"_id": "fleet-synced-integrations",
"_score": 1,
"_source": {
"remote_es_hosts": [
{
"name": "remote1",
"hosts": [
"http://192.168.64.1:9200"
],
"sync_integrations": true
}
],
"integrations": [
],
"custom_assets": {
"ingest_pipeline:filestream-pipeline1": {
"type": "ingest_pipeline",
"name": "filestream-pipeline1",
"package_name": "filestream",
"package_version": "1.1.0",
"is_deleted": false,
"pipeline": {
"processors": [
{
"set": {
"field": "test_field",
"value": "value"
}
}
],
"version": 2
}
}
}
}
GET fleet-synced-integrations-ccr-main/_search
# same content should be in the ccr index
```
<img width="2545" alt="image"
src="https://github.com/user-attachments/assets/127e5e6e-cf7e-4549-817d-88df10f4f523"
/>
### Checklist
- [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
## Summary
Discover Data View picker has the ability to indicate whether or not the
DV is "managed", meaning - owned by the app,
where modifications done by the user are preceeded with a warning (when
changing the index pattern).
This PR filters some of the data views we know should be managed
(currently the default security one), and passes them to the Data View
Picker in a way that renders the following label next to the data view
in the dropdown:
<img width="1134" alt="Screenshot 2025-04-03 at 09 42 42"
src="https://github.com/user-attachments/assets/825dd98b-b54b-4ba5-9f2c-014ad35357be"
/>
## Testing
Add the following feature flag to your configuration:
`xpack.securitySolution.enableExperimental:
['newDataViewPickerEnabled']`
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
## Summary
Partially address https://github.com/elastic/kibana/issues/216459
This PR adds `@emotion/babel-preset-css-prop` to jest config to improve
jest and emotion integration. There are some tradeoffs: this is a better
setup for emotion + testing library, but there are some seemingly
regressions for enzyme. We think these are right tradeoffs to make,
since we optimize for emotion+testing library.
### Main upsides are 😄
#### 🟢 Fixes snapshots with css prop
`You have tried to stringify object returned from \`css\` function. It
isn't supposed to be used directly (e.g. as value of the \`className\`
prop), but rather handed to emotion so it can handle it (e.g. as value
of \`css\` prop).` is replaced with proper emotion css classname.
#### 🟢 We will be able to use jest style matchers for emotion
`toHaveStyleRule`
https://emotion.sh/docs/@emotion/jest#tohavestylerule
_they can be used locally now, but we plan to follow up with global
extend_
### Considerations 🫤
#### 🟡 jsx doesn't work inside jest.mock function
Example:
```
jest.mock('./components/alert_header_title', () => ({
> 27 | AlertHeaderTitle: jest.fn().mockReturnValue(<div></div>),
| ^
28 | }));
```
Fails with an error. `can't read jsx of undefined`.
This is because babel compiles this into:
```
import { jsx as ___EmotionJSX } from '@emotion/react'
jest.mock('./components/alert_header_title', () => ({
> 27 | AlertHeaderTitle: jest.fn().mockReturnValue(___EmotionJSX.jsx(….)),
| ^
28 | }));
```
And, apparently, due to how jest imports work, __EmotionJSX is not yet
in the scope.
The applied workaround is to rewrite to:
```
jest.mock('./components/alert_header_title', () => ({
AlertHeaderTitle: jest.fn(() => <div></div>),
}));
```
#### 🟡 euiTheme needs to be available when euiTheme is accessed inside
`css` function
Example:
```
DashboardGrid removes panel when removed from container
TypeError: Cannot read properties of undefined (reading 'size')
42 | margin: '-2px',
43 | position: 'absolute',
> 44 | width: euiTheme.size.l,
```
The fix was to wrap failing tests with `<EuiProvider/>`
### Drawbacks 😢
Mostly related to Enzyme
#### 🔴 Enzyme shallow snapshot no longer include `css` prop
Since `css` prop is compiled away there are bunch of snapshots that
looks like a regression:
Example:
This is unfortunate. We've tried `@emotion/jest/enzyme-serializer` but
it didn't work (likely because enzyme ecosystem no longer supported?)
If it is important that the snapshot captures css, we recommend to use
mount or rtl
#### 🔴 Asserting against `css` prop with shallow render also doesn't
work
Possible solution is to use
```
import { matchers } from '@emotion/jest';
expect.extend(matchers);
```
(We plan to add these matches globally in a follow up)
and
```
expect(button).toHaveStyleRule('background-color', '#FFFFFF');
```
#### 🔴 Some shallow Enzyme tests `find()` breaks because of code
transformations of emotion
Example:
```
const component = shallow(
<MetricVisValue />
)
component.find('button') // fails because instead of <button/> there is <EmotionInternalCss/> element now
```
Solutions:
- Use full mount or react testing library
- Or target by data-test-subj
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Karen Grigoryan <karen.grigoryan@elastic.co>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## 📓 Summary
Closes#217884
- Updates the condition editor to have a more consistent behaviour for
enabled/disabled routing.
- A more explicit tooltip is added to describe how the status flag
affects the routing behaviour.
- The status switch is visible by default, while before it was shown
only in edit mode for a routing condition.
- Fixed crashes when manually working on the syntax editor.
- Removes the routing status flag from the condition editor in the
processors' config.
<img width="763" alt="Screenshot 2025-04-14 at 10 23 42"
src="https://github.com/user-attachments/assets/8521739a-ac53-4751-9ad3-4400a84c5a8d"
/>
## Summary
Adds a basic sanity check before pulling a value from the target object.
Under the hood `lodash` will drive this check by running `Object.
hasOwnProperty` for each segment of the path we are querying. Guards
against theoretical attacks from SOs that might allow ill-defined
structures in documents.
### Checklist
- [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
## Summary
Bootstrap the initial page structure for Privileges User Monitoring
Onboarding Workflow
### What's included
* Create Entity Analytics Page
* Create Privileged User Monitoring Page
* Add the pages to the SecuritySolution and the global menu
* Hide the page when the experimental flag is disabled
`privilegeMonitoringEnabled`
### What's not included
* The content of the Entity Analytics and Privileged User Monitoring
pages
### Answered Questions
* The path `entity_analytics` has already been taken. I chose
`entity_analytics_landing`
* Should the link show up on the global EA page? Yes
* Navigation Menu for ESS? Good for now
* Which permission/capabilities are required? Same as risk engine
### How to test it?
* You only need to run Kibana and check if the navigation item is in the
menu
* The page should show up on the global nav
* The page should show up on the global search bar
* Visibility constraints
* It should be hidden when `privilegeMonitoringEnabled` is not enabled
* It should be visible when the user has access to the entity analytics
feature
* It should be visible for platinum users
### Checklist
- [x] 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/src/platform/packages/shared/kbn-i18n/README.md)
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
The listing page didn't handle "orphaned" streams properly (classic data
streams which have a configuration on the stream level but the
underlying data stream is not available because it got deleted).
This PR fixes that and adds an integration test for it
<img width="774" alt="Screenshot 2025-04-10 at 16 07 15"
src="https://github.com/user-attachments/assets/da15c56b-7dbd-4070-ab6d-4235132da8ed"
/>
In this picture, `logs-test-default` is orphaned.
To test:
* Create a new classic stream (e.g. via executing
```
POST logs-mylogs-default/_doc
{ "message": "Test" }
```
* Go into the streams UI and add a processor for this stream
* Delete the data stream via stack management or via
```
DELETE _data_stream/logs-mylogs-default
```
* Go to the streams listing page
## Summary
It seems there's been some sort of unintended bundle limit branch
through 2 minor changes (greenlit separately on PRs) - and this one
broke the camel's back: https://github.com/elastic/kibana/pull/212163
## Summary
Epic: https://github.com/elastic/kibana-team/issues/1435
Closes https://github.com/elastic/kibana/issues/205413
Closes https://github.com/elastic/kibana/issues/205411
This PR creates a new way to expose stateful service dependencies needed
for rendering React elements in Kibana. The concept of the changes is
that `KibanaRenderContextProvider` should not be a shared module, but
should be wrapped by a core service (the `RenderContextService` name is
TBD). The next steps in this direction would be to coordinate teams to
migrate away from directly using `KibanaRenderContextProvider`.
### Background
Today, the dependencies for `KibanaRenderContextProvider` are declared
as separate services which can be found in the `CoreStart` context. This
has created a situation where enhancing the module with more
dependencies creates widespread changes needed for the UI codebase.
The @elastic/appex-sharedux team is looking to solve this situation by
defining a less impactful way to make future enhancements. The solution
is one that can be gradually migrated towards, so the SharedUX team can
ask Kibana contributors to migrate towards in their own code. This PR
offers a POC for that solution.
### Details of this POC
The driving goal for this refactor is to lessen the impact across the
Kibana codebase whenever the `KibanaRenderContext` module needs to
require additional services from the `CoreStart` context.
#### Rendering a React Element with `ReactDOM.render`: Before
```tsx
const renderApp = ({ core, targetDomElement }: { core: CoreStart; targetDomElement: HTMLElement; }) => {
// If `KibanaRenderContextProvider` needs to expand its scope, more services could be needed here,
// updating all the places throughout the code to pass those is a ton of work 👎🏻
const { i18n, theme, analytics, userProfile, executionContext } = core;
ReactDOM.render(
<KibanaRenderContextProvider {...{ i18n, theme, analytics, userProfile, executionContext }}>
<MyApplication />
</KibanaRenderContextProvider>,
targetDomElement
);
return () => ReactDOM.unmountComponentAtNode(targetDomElement);
};
```
#### Rendering a React Element with `ReactDOM.render`: After
```tsx
const renderApp = ({ core, targetDomElement }: { core: CoreStart; targetDomElement: HTMLElement; }) => {
// So much less code, so much more future-proof 👍🏻
ReactDOM.render(core.rendering.addContext(<MyApplication />), targetDomElement);
return () => ReactDOM.unmountComponentAtNode(targetDomElement);
};
```
### Alternatives considered
See https://github.com/elastic/kibana/pull/209161
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
### FAQ
1. **Q**: This is React-centric. Does this give Kibana more commitment
towards React?
**A:** For now, yes. But if we want to Kibana to remain
framework-agnostic we may be able to add more extensions to the
RenderContextService that support other frameworks.
1. **Q:** Why not have a service that wraps `ReactDOM.render`?
**A:** As we steer towards upgrading to React 18 in Kibana, staying
agnostic of how React is rendered benefits us. React 18 has different
ergonomics based on whether you want to update an existing tree or mount
a new one.
1. **Q:** Does the API have to be named `rendering.addContext`?
**A:** No, it does not. Please suggest a better name if you have one in
mind.
1. **Q:** What are the next steps?
**A:** Refer to the
[Epic](https://github.com/elastic/kibana-team/issues/1435). This PR
started as a POC but became ready for merge. After it is delivered to
the codebase, the next steps are to improve documentation and engage in
"sheparding." That is, socialize the new way of injecting dependencies
into the context, support teams in their migration, and track the
progress of migration.
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [x] Care is needed to ensure this doesn't not negatively impact
performance with unnecessary re-renders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [cytoscape](http://js.cytoscape.org)
([source](https://redirect.github.com/cytoscape/cytoscape.js)) |
dependencies | patch | [`^3.31.1` ->
`^3.31.2`](https://renovatebot.com/diffs/npm/cytoscape/3.31.1/3.31.2) |
---
### Release Notes
<details>
<summary>cytoscape/cytoscape.js (cytoscape)</summary>
###
[`v3.31.2`](https://redirect.github.com/cytoscape/cytoscape.js/releases/tag/v3.31.2)
[Compare
Source](https://redirect.github.com/cytoscape/cytoscape.js/compare/v3.31.1...v3.31.2)
Release version v3.31.2
</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://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Sergi Romeu <sergi.romeu@elastic.co>
# Only merge this if you want streams to go public
This PR changes the logic for the client side "status$" observable for
streams to look for whether it's on serverless in an observability
project (because this is where we want to launch first).
Later on, this logic can be adjusted as necessary for on-prem launches
etc.
To make this work locally, you need to add
`xpack.cloud.serverless.project_id: "project_id"` to your
`config/kibana.dev.yml`
It still shows the streams app if wired streams are enabled (basically
it keeps the old behavior plus always defaulting to `enabled` if it's an
observability serverless project.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
