## 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>
## Summary
Closes https://github.com/elastic/kibana/issues/215335
Currently, when an agent policy is duplicated, shared integration
policies are also duplicated. This PR adds logic where the duplicated
agent policy also shares these integration policies.
### Testing
* Run ES with an [Entreprise
license](https://www.elastic.co/subscriptions) to avail of reusable
integration policies.
* Create an agent policy with a shared integration policy and a
non-shared integration policy.
* Duplicate the agent policy: the duplicated policy should only
duplicate the non-shared integration policy and the shared integration
policy should be reused.
### 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
- [ ] 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)
### Identify risks
Incorrect package policies in duplicated agent policies.
## Summary
Fixes the #207204
This PR introduces a new complementary function for an Expression
definition named `sideEffects`, this goes together with the other `fn`
function and it is used to restore any side effect when the caching
system kicks in.
I haven't found how to programmatically test this.
Will add an FTR if it can be reliable to reproduce an expression caching
scenario.
### 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
### Release notes
The request inspector now shows the correct request and response in any
successful scenario.
## Summary
This PR introduces the first building blocks for the [Entity Analytics
Privileged
Monitoring](https://github.com/elastic/security-team/issues/9971).
We follow the approach used in the Entity Store and add a new "Engine",
which consists of the following components:
* Public API
* INIT and HEALTH routes
* Kibana task
* Privilege Monitoring Data Client
* Engine Saved Object
* API key manager
* Related storage indices
* Feature Flag: `privilegeMonitoringEnabled` set to `false` by default.
* API integration test configuration
* only tests that the health endpoint is available
* Auditing and Telemetry
## Testing steps
1. Make sure to add `privilegeMonitoringEnabled` to your
`kibana.dev.yaml`
2. In devtools, ensure the API is working with `GET
kbn:/api/entity_analytics/monitoring/privileges/health`
3. Start the engine with: `POST
kbn:/api/entity_analytics/monitoring/engine/init`
4. Look for `DEBUG` logs mentioning the
`entity_analytics:monitoring:privileges:engine` task
---------
Co-authored-by: CAWilson94 <charlotte.wilson@elastic.co>
Co-authored-by: Charlotte Alexandra Wilson <CAWilson94@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[Preconfigured
connectors](https://www.elastic.co/guide/en/kibana/current/pre-configured-connectors.html)
are those that are specified via the `kibana.yml` config, and thus they
can't be deleted. In tests, we've hardcoded their ids to skip deleting
them when we need to clean up the tests' state.
Sometimes, the id of a preconfigured connector gets changed by somebody,
which breaks tests of multiple teams in MKI pipelines, such as the
periodic pipeline or the release quality gates. The problem is that it
doesn't happen on CI where Kibana doesn't have any preconfigured
connectors, so this feedback loop is too long. When tests in an MKI
pipeline break, it's not immediately clear what happened and who should
fix it. Eventually it gets fixed by someone [like
this](https://github.com/elastic/kibana/pull/217570/files).
Instead of hardcoding the ids, we should dynamically determine if a
connector is preconfigured and if it should be deleted by a test or not.
This is possible to do as each connector has the corresponding
`is_preconfigured` property.
<img width="1073" alt="Screenshot 2025-04-10 at 14 16 15"
src="https://github.com/user-attachments/assets/e330cd5f-c9f0-43da-b4b4-f2a0a2fd10a5"
/>
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [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)
## Summary
Fixes https://github.com/elastic/kibana/issues/217935 (in the quickest
way possible for now).
## Possible followups
- We could potentially move these advanced parameters to a sub object.
However, the idea was that `FieldDefinitionConfig` utilises a union of
`MappingProperty` (from ES) so that this wasn't needed 🤔
- The types can definitely be improved (`getAdvancedParameters` takes in
`fieldConfig: FieldDefinitionConfig` and this missed the possibility of
`InheritedFieldDefinitionConfig`, for example). We could also make the
stripping schema driven.
## 📓 Summary
Fixes a link targeting the overview page while it should have gone to
the management section.
Also fixes broken redirect when targeting `/{key}/management`
## Summary
- Fix a bug that was causing failing tool invocations to not being
persisted to the conversation history, corrupting the conversation for
following rounds.
- Optimize the researcher's prompts (leading to ~50% latency cut, mostly
on the summarization step)
Closes https://github.com/elastic/kibana/issues/210979
## Summary
- This PR updates the rules list and rules details pages to hide actions
for the users with read-only access. Previously, these actions were
disabled, but now they are completely hidden. Specifically:
- on the `Rules List` page, the snooze bell icon and the table row
actions are now hidden for the users with read-only access
- on the `Rule Details` page, the actions button is now hidden
(previously, the users could click on it, but the options were disabled)
<img width="1899" alt="Screenshot 2025-04-02 at 14 06 53"
src="https://github.com/user-attachments/assets/712297bf-b807-4ecc-87da-a32cd67d169f"
/>
<img width="1899" alt="Screenshot 2025-04-02 at 14 07 06"
src="https://github.com/user-attachments/assets/a88762fa-feeb-4117-9dc4-31744c752d82"
/>
## Summary
Renaming types and files as well as moving providers around to make
implmentating saved playground routes more straightforward. Naming
updates to reduce future confusion from generic names that didn't fit
when there are multiple providers etc.
