`useBatchedOptionalPublishingSubjects` should only be used when `api` is
not available until after rendering. This PR replaces usages of
`useBatchedOptionalPublishingSubjects` with
`useBatchedPublishingSubjects` where possible.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR addresses the issue where if user tried to renavigate to
Findings page (with filter on) from Vulnerability Contextual Flyout by
clicking on the popup icon in the Vulnerability Details table the filter
on Findings page won't get formed properly IF some of the fields value
contains special character such as "+", this happen when user gets
redirected to Findings page
in the case of "+", this malformed filter is caused because in the URL
"+" gets encoded into "%20" which is space instead of "%2b" which is "+"
https://github.com/user-attachments/assets/ce4007a1-b0ad-4ce4-b389-53c44a43aa9b
Part of https://github.com/elastic/kibana/issues/216491
Adds telemetry for linked dashboards and investigation guide fields that
are coming soon: https://github.com/elastic/kibana/issues/214522,
https://github.com/elastic/kibana/issues/213024
- Number of rules with linked dashboards
- Number of rules with non-empty investigation guide
To test, you can use the following API call. The result should include
two new fields: `count_rules_with_linked_dashboards` and
`count_rules_with_investigation_guide`
```
POST kbn:/internal/telemetry/clusters/_stats?apiVersion=2
{
"unencrypted": true,
"refreshCache": true
}
```
### Note
I have added a comment to update one test file
(`x-pack/test/alerting_api_integration/common/lib/get_test_rule_data.ts`)
once `artifacts` field is available in schema.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from `x-pack/test` to
`x-pack/platform/test`
Before:
```
x-pack/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
After:
```
x-pack/platform/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
Additional:
- `x-pack/test/api_integration/apis/osquery/config.ts` was move to
platform stateful manifest to match `osquery` plugin (shared, platform)
- `automatic_import_api_integration` config files were moved to platform
stateful manifest to match `automatic_import` plugin (shared, platform)
- `x-pack/test/common/lib/test_data_loader.ts` is required by SO api
tests and was copied to `x-pack/platform/test/common`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#220289 and
https://github.com/elastic/opentelemetry-lib/issues/168
## Summary
This PR fixes an issue with the processes query in case the document is
missing some of the required fields for the aggregation (like user.name,
process.pid, system.process.cpu.total.pct, etc.). This PR adds a filter
to the query to ensure that all the required fields exist
| Before | After |
| ------ | ------ |
|
|
|
## Testing
> [!NOTE]
> With the oblt lite cluster, the issue is reproducible as in the
screenshot (one of the hosts using the hostsmetrics receiver),
I also tested with metricbeat for regressions and the host Otel
Onboarding steps locally (the processes are not available there, just
the summary)
- Go to the asset details page and open the processes tab
- There shouldn't be an error shown when loading the processes
## Summary
- Changes the location of any captured Elastic agent diagnostics files
during a cypress tests failure to `target/agent_diagnostics` from
`target/test_failures`
Follow on from this PR that was merged,
https://github.com/elastic/kibana/pull/213550
## Summary
This PR updates the ES|QL grouping processing to work with the
`context.grouping` action variable.
### Checklist
- [ ] [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
### To verify
1. Create an ES|QL rule with grouping.
2. In "active" and "recovered" action message, use `context.grouping`
variable
3. Verify that both "active" and "recovered" alert notifications contain
correct information
Example if grouping on `host.name` and `container.id`:
```
{
"grouping": "{{context.grouping}}",
"host.name": "{{context.grouping.host.name}}",
"container.id": "{{context.grouping.container.id}}"
}
```
This pull request introduces enhancements and bug fixes across multiple
components in the security solution plugin. Key updates include
improvements to the DonutChart component, support for ESQL queries in
the Inspect Modal, and the addition of new hooks and components for
privileged user monitoring. The changes also include minor refactoring
and optimizations.
### DonutChart Enhancements and Refactoring:
* Updated `max-width` in the `donutTextWrapper` style to use a
percentage for better responsiveness. (`donutchart.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/common/components/charts/donutchart.tsxL81-R81](diffhunk://#diff-56039022d9e7cfcdda9c26e0566e5cd5f23dbb8e6c4806c6b2e39bdcee605cd2L81-R81))
* Replaced the `style` prop with the `css` prop for better integration
with Emotion styling. (`donutchart.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/common/components/charts/donutchart.tsxL142-R142](diffhunk://#diff-56039022d9e7cfcdda9c26e0566e5cd5f23dbb8e6c4806c6b2e39bdcee605cd2L142-R142))
* Simplified the `onPartitionClick` logic by removing the
`.toLowerCase()` transformation. (`donutchart.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/common/components/charts/donutchart.tsxL181-R181](diffhunk://#diff-56039022d9e7cfcdda9c26e0566e5cd5f23dbb8e6c4806c6b2e39bdcee605cd2L181-R181))
### ESQL Query Support in Inspect Modal:
* Added `lodash/fp`'s `isString` utility to handle conditional logic for
ESQL vs. JSON formatting. (`modal.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/common/components/inspect/modal.tsxR28](diffhunk://#diff-e7bd02a3f01d8b88dea1df92d5f27d7d9c13bc8e59ae0c1ff4396f1eb139e340R28))
* Dynamically set the `language` attribute in `EuiCodeBlock` based on
the request body type. (`modal.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/common/components/inspect/modal.tsxL251-R252](diffhunk://#diff-e7bd02a3f01d8b88dea1df92d5f27d7d9c13bc8e59ae0c1ff4396f1eb139e340L251-R252))
* Enhanced the rendering of the request body to support both raw and
stringified formats. (`modal.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/common/components/inspect/modal.tsxL260-R263](diffhunk://#diff-e7bd02a3f01d8b88dea1df92d5f27d7d9c13bc8e59ae0c1ff4396f1eb139e340L260-R263))
### Privileged User Monitoring:
* Introduced a new `RiskLevelsPrivilegedUsersPanel` component with a
DonutChart and table for visualizing privileged user risk levels.
(`risk_level_panel/index.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/entity_analytics/components/privileged_user_monitoring/components/risk_level_panel/index.tsxR1-R150](diffhunk://#diff-db56c23ac70dfb3daed48e12703939a97b342e66ef37a2fb37b12443b872393dR1-R150))
* Added supporting hooks (`useRiskLevelsPrivilegedUserQuery`,
`useRiskLevelsTableColumns`) and constants for privileged user
monitoring. (`risk_level_panel/hooks.tsx`,
[[1]](diffhunk://#diff-43a65c138415c204a947839568ba745f55b03e137dddc6081b551b116530f672R1-R124);
`risk_level_panel/constants.ts`,
[[2]](diffhunk://#diff-3d45970aca50b5e25ee79b7399245b08225060a91e63436eeb67721f9332276dR1-R22)
* Created a wrapper component `PrivilegedUserMonitoring` to organize
different panels related to privileged user insights. (`index.tsx`,
[x-pack/solutions/security/plugins/security_solution/public/entity_analytics/components/privileged_user_monitoring/index.tsxR1-R44](diffhunk://#diff-273ad32c97dcf15c6c6054fd7c5516d587132674578d25986b235cd174c75789R1-R44))
### New Hooks for Query Management:
* Added `useEsqlQueryWithGlobalFilters` to facilitate ESQL query
construction with global filters.
(`use_esql_query_with_global_filter.ts`,
[x-pack/solutions/security/plugins/security_solution/public/common/hooks/esql/use_esql_query_with_global_filter.tsR1-R28](diffhunk://#diff-a6205e70128171bfa6f6aa85e3b4090c18740033696f41667fe5f7140b309036R1-R28))
* Introduced `useAddFilter` for dynamically adding filters to the Kibana
filter manager. (`use_add_filter.ts`,
[x-pack/solutions/security/plugins/security_solution/public/common/hooks/use_add_filter.tsR1-R33](diffhunk://#diff-eb285a6a89e7f3641339b8c3b1823add89ccd1e721d5820030691998a8dd35f1R1-R33))
### Minor Refactoring:
* Removed unused parameters from `useGetDefaultRiskIndex` calls to
simplify API usage. (`use_risk_score.tsx`,
[[1]](diffhunk://#diff-cd4a1ef2e228a140ee7b2d6408f70759864d3e10074094a56f33e32950d2f67aL76-R76);
`use_risk_score_kpi.tsx`,
[[2]](diffhunk://#diff-a717e9611a5489f1b092575c183229d98af1abbdddf78a2fa1a6d95f00969843L48-R48)
Summary
### How to test it?
1. Check out Mark's privmon document generator branch
https://github.com/elastic/security-documents-generator/pull/104
2. Run `yarn start privmon`
3. Start Kibana with the flag `privilegeMonitoringEnabled` enabled
4. Go to privmon page using the many and click in the top link
5. Play with the brand new visualisation
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [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#184907
This PR introduces the Trend badge feature into the Secondary Metric
chart type.
<img width="1318" alt="Screenshot 2025-04-30 at 13 04 36"
src="https://github.com/user-attachments/assets/6b3c599e-304f-4bc0-8ff2-094ed54ea248"
/>
<img width="1503" alt="Screenshot 2025-04-30 at 13 04 03"
src="https://github.com/user-attachments/assets/cb203156-a7a8-4f61-bf30-57f7d1484fed"
/>
<img width="1339" alt="Screenshot 2025-04-30 at 13 03 21"
src="https://github.com/user-attachments/assets/8896af7f-9193-41b5-a4b5-970907b084c5"
/>
<img width="1319" alt="Screenshot 2025-04-30 at 13 05 34"
src="https://github.com/user-attachments/assets/12aa556e-8743-4167-9902-14fa9ef2e85d"
/>
Here's a short list of tasks handled by this PR:
* [x] New Color by value option: `None` | `Static` | `Dynamic`
* Default `None` option is the default (legacy preserved)
* [x] `Static` option enables the badge with the picked color
* [x] this is also enforced when the Primary metric is not number based
(or when primary transition from number to text)
* [x] `Dynamic` option enables both the badge coloring and the icon
* [x] When disabled a tooltip with the explanation of the issue appears
* [x] Trend palette is enabled by default on enable
* [x] Added other 3 extra palettes (`Reversed`, `Temperature`,
`Complementary`)
* [x] Each palette has been implemented using both EUI tokens AND Vis
tokens
* [x] Revisited this decision ♻️
* [x] Remove redundant palettes
* ~~keep only Vis palettes & hardcode `green` value for now.~~
* ~~Once EUI exposes the green token integrate in a follow up.~~
* Use the `@kbn/palettes` service with the new `compare_to` palette with
hardcoded values
* [x] Exposes display options: `Icon` | `Value` | `Both`
* [x] `Both` is the default
* [x] `Icon` or `Both` will show up 3 possible icon options: arrow up,
arrow down and equal sign from unicode
* [x] Make sure both text and icon respect breakpoint sizes
* [x] Remove hack for breakpoints ( Lens Embeddable + Secondary metric)
once new Charts upgrade is merged:
https://github.com/elastic/elastic-charts/pull/2627
* [x] Remove `theme` and contrast color computation once the Elastic
Charts PR above is merged
* [x] Make sure badge is always accessible
* [x] Exposes Trend options: `Static value` | `Primary metric`
* [x] `Static value` will show up a new `Baseline` control (debounced)
* [x] `Primary metric` is enabled only for numeric primary values
* [x] When disabled a tooltip shows up explaining the issue
* [x] Added description text to explain difference with the other
compare mode
* [x] Show only delta value when in Primary
* [x] Migrated existing `metric_vis` tests from Enzyme to RTL
* [x] New tests for the new Secondary metric component in RTL
* [x] Added new smoketest + panel mode caching testing for the metric
feature in FTR
Few aspects of this feature have been discussed and deferred to a follow
up issue: https://github.com/elastic/kibana/issues/217992
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nick Partridge <nick.ryan.partridge@gmail.com>
Resolves: https://github.com/elastic/kibana/issues/216308
This PR adds rrule notation support to the task scheduling.
Currently we use a simple interval string (such as `1h` or `45m`) to
calculate the next `runAt` that we use to decide if the task should be
picked up or not. With this PR, we will be able to use rrule as well.
We set the `runAt` field in 3 places:
- At task creation: when the task is created for the first time, this is
always `now` if a specific runAt is not provided.
- At task update. We update runAt on task update as well but only when
it is provided. We don't update it when the schedule config changes.
- After task run: to decide when the next run will be after a task is
run.
This PR modifies:
- At task creation: It still uses the `runAt` when it is provided but
calculates a runAt by using rrule if the config has a fixed time (like
every day at 13:00) config. Becausethe task should not run immediately
when there is a fixed time to run.
- After task run: It calculates the next `runAt` with rrule when it is
provided.
This PR doesn't apply any change on `At task update` as it requires a
further investigation and consideration. We will handle it with a
follow-on issue.
## To verify:
You can use the test task `sampleRecurringTask` to test the feature.
Just create a task with rrule in the schedule config.
Then check the runAt field in the task SO to see if it is the expected
datetime.
Then run the task one more time and check the new `runAt`
I also used the usage reporting task in the actions plugin to test the
feature.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of #218501
This PR removes the advanced setting
`observability:enableInfrastructureAssetCustomDashboards` but keeps the
saved object, to be removed in a [follow-up
issue](https://github.com/elastic/kibana/issues/220340).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#217331
Each tab shows loading indicator if the query is running.
https://github.com/user-attachments/assets/3c7bea34-c365-4038-ad42-636985e5a3db
~~I used the preview data here, as we already have the functionality of
observing changing status, I didn't want to replicate this logic. I'm
open to suggestions though, if for any reason `getPreviewData` shouldn't
be invoked here or be invoked only here and passed down to preview
component.~~
Edit: after syncing with @davismcphee, I lifted the `getPreviewData`
call up, so it's called once
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] 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 was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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
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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: jennypavlova <dzheni.pavlova@elastic.co>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Nikita Indik <nikita.indik@elastic.co>
Co-authored-by: Patrick Mueller <patrick.mueller@elastic.co>
Co-authored-by: Søren Louv-Jansen <soren.louv@elastic.co>
Co-authored-by: Elena Shostak <165678770+elena-shostak@users.noreply.github.com>
Co-authored-by: Brad White <Ikuni17@users.noreply.github.com>
Co-authored-by: Robert Jaszczurek <92210485+rbrtj@users.noreply.github.com>
Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co>
Co-authored-by: Charis Kalpakis <39087493+fake-haris@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
Co-authored-by: Jesus Wahrman <41008968+jesuswr@users.noreply.github.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@elastic.co>
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
Co-authored-by: Kylie Meli <kylie.geller@elastic.co>
Co-authored-by: Anton Dosov <anton.dosov@elastic.co>
Co-authored-by: Saarika Bhasi <55930906+saarikabhasi@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
Co-authored-by: Viduni Wickramarachchi <viduni.ushanka@gmail.com>
Co-authored-by: Mason Herron <46727170+Supplementing@users.noreply.github.com>
Co-authored-by: Khristinin Nikita <nikita.khristinin@elastic.co>
Co-authored-by: Julia Rechkunova <julia.rechkunova@elastic.co>
Co-authored-by: Eyo O. Eyo <7893459+eokoneyo@users.noreply.github.com>
Co-authored-by: Michel Losier <michel.losier@elastic.co>
Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
Co-authored-by: Krzysztof Kowalczyk <krzysztof.kowalczyk@elastic.co>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
Co-authored-by: Devin W. Hurley <devin.hurley@elastic.co>
Co-authored-by: Panagiota Mitsopoulou <panagiota.mitsopoulou@elastic.co>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Co-authored-by: Nathan Reese <reese.nathan@elastic.co>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
Co-authored-by: Florian Lehner <florianl@users.noreply.github.com>
Co-authored-by: Paulina Shakirova <paulina.shakirova@elastic.co>
Co-authored-by: Milosz Marcinkowski <38698566+miloszmarcinkowski@users.noreply.github.com>
Co-authored-by: Sergi Romeu <sergi.romeu@elastic.co>
## Summary
This PR introduces basic CRUD routes for handling Privileged Users in
Entity Analytics.
The following routes are available:
* CREATE: `POST /api/entity_analytics/monitoring/users`
* GET: `GET /api/entity_analytics/monitoring/users/{id}`
* LIST: `GET /api/entity_analytics/monitoring/users/list`
* UPDATE: `PUT /api/entity_analytics/monitoring/users/{id}`
* DELETE: `DELETE /api/entity_analytics/monitoring/users/{id}`
For CREATE and UPDATE, the request body should be of type:
```
{ "user_name": string, is_monitored: boolean }
```
The reason for snake_case is to align better with the upcoming csv and
json upload work.
This PR already introduces boilerplate code (registering the endpoints
and handlers) for those routes). We might want to change this.
## How to test
1. Start a fresh Kibana instance
2. Enable the `EntityAnalyticsPrivilegeMonitoring` Feature Flag.
3. Initialise the privmon engine with `POST
kbn:/api/entity_analytics/monitoring/engine/init`
4. Test any of the endpoints above
* Make sure to either note down the returned `id`s or simply query the
underlying index: `.entity_analytics.monitoring.users-<your namespace>`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds data view retrieval from the new data view manager / picker
wherever we are using `useGetScopedSourcererDataView` now, with the
intention of removing the latter eventually (when new picker is
stabilized).
Related issue: https://github.com/elastic/security-team/issues/12569
Parent epic: https://github.com/elastic/security-team/issues/11959
### Testing
Add the following flag to your config
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
- With the feature flag off, the app should not break.
- When the flag is on, data view information should be retrieved based
on the selection / active data view obtained from the new data view
manager.
### 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
As the Span/Transaction name and id were moved to be the Title/Subtitle
of the Span/Transaction document overview, they initially lost the field
actions popover they had before. This PR adds the popover back.
Closes#220066
### How to test
* Add this to your `kibana.dev.yml` file:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Enable the Observability mode for the current space, then navigate to
Discover
* Create/use a data-view or use an ES|QL query that targets a `traces-*`
index.
* Open the overview for a resulting Span/Transaction and hover over the
title/name. A popover should appear.
## Summary
This PR implements a mechanism to control visibility and access to
Security Solution pages based on user access and PLIs.
It replaces direct usage of the `SecurityRoutePageWrapper` component
with the `withSecurityRoutePageWrapper` higher-order component across
multiple route files in the Security Solution plugin.
## Changes
- Added `cloudSecurityPosture` entry to the `SecurityPageName` enum in
`deep_links.ts`
- Replaced direct usage of `SecurityRoutePageWrapper` with
`withSecurityRoutePageWrapper` HOC in:
| Route | Complete | AiSoc | Comments |
|-------------------------|----------|--------------------------------|----------------------|
| Asset Inventory routes | OK | Redirected to /get_started | |
| Assets routes | OK | OK | Should we hide this one? |
| Cloud Security Posture | Redirected to /get_started | Redirected to
/get_started | Redirected if there's no 'Cloud' Addon (even on Complete)
|
| Dashboards routes | OK | Redirected to /get_started | |
| Exceptions routes | OK | Upselling | Upselling has priority over
redirection |
| Explore routes | OK | Redirected to /get_started | |
| Investigations routes | OK | Redirected to /get_started | |
| Notes routes | OK | Not Working | Should be redirected to get_started
- TBC... |
| Overview routes | OK | Redirected to /get_started | |
| Timelines routes | OK | Redirected to /get_started | |
## Question:
<img width="1227" alt="Screenshot 2025-04-24 at 15 20 52"
src="https://github.com/user-attachments/assets/a57936b9-e954-43d8-a6d0-caf31508461c"
/>
Without `Cloud` Add-on - should we hide the cloud cards ? Eg. in
`Complete` tier?
## Technical Details
The `withSecurityRoutePageWrapper` HOC provides a consistent way to
handle authorization, redirects, and page visibility across the Security
Solution.
This approach allows for more granular control over which pages are
accessible based on user permissions and subscription tier, particularly
important for the **AI for SOC** functionality.
## Testing
- Verified that all Security Solution pages properly respect user
permissions
- Confirmed that unauthorized users are redirected appropriately
Closes: https://github.com/elastic/security-team/issues/12401
---------
Co-authored-by: Ash <1849116+ashokaditya@users.noreply.github.com>
Co-authored-by: Ashokaditya <ashokaditya@elastic.co>
Instrument the inference chatComplete API with OpenTelemetry, and export
helper functions to create spans w/ the right semconv attributes.
Additionally, optionally export to Langfuse or Phoenix.
## Centralizes OpenTelemetry setup
As this is the first instance of OpenTelemetry based _tracing_ (we
already have metrics in the MonitoringCollection plugin), some
bootstrapping code is necessary to centrally configure OpenTelemetry. To
this end, I've added the following config settings:
- `telemetry.tracing.enabled`: whether OpenTelemetry tracing is enabled
(defaults to undefined, if undefined, falls back to `telemetry.enabled`)
- `telemetry.tracing.sample_rate` (defaults to 1)
The naming of these configuration settings is mostly in-line with [the
Elasticsearch tracing
settings](https://github.com/elastic/elasticsearch/blob/main/TRACING.md).
The following packages (containing bootstrapping logic, utility
functions, types and config schemas) were added:
- `@kbn/telemetry`
- `@kbn/telemetry-config`
- `@kbn/tracing`
The OpenTelemetry bootstrapping depends on @kbn/apm-config-loader, as it
has the same constraints - it needs to run before any other code, and it
needs to read the raw config.
Additionally, a root `telemetry` logger was added that captures
OpenTelemetry logs.
Note that there is no default exporter for spans, which means that
although spans are being recorded, they do not get exported.
## Instrument chatComplete calls
Calls to `chatComplete` now create OpenTelemetry spans, roughly
following semantic conventions (which for GenAI are very much in flux).
Some helper functions were added to create other inference spans. These
helper functions use baggage to determine whether the created inference
span is the "root" of an inference trace. This allows us to export these
spans as if it were root spans - something that is needed to be able to
easily visualize these in other tools.
Leveraging these inference spans, two exporters are added. One for
[Phoenix](https://github.com/Arize-ai/phoenix) and one for
[Langfuse](https://github.com/langfuse/langfuse/tree/main): two
open-source LLM Observability suites. This allows engineers that use the
Inference plugin to be able to inspect and improve their LLM-based
workflows with much less effort.
For both Phoenix and Langfuse, two service scripts were added. Run `node
scripts/phoenix` or `node scripts/langfuse` to get started. Both scripts
work with zero-config - they will log generated Kibana config to stdout.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This change adds onboarding ID to the "Copy To Clipboard" button in Auto
Detect flow. This ID is needed to correctly connect BI events during the
flow.
**Note about backports**
I'm going to add backport labels for 8.18 and 9.0 after 8.18.1 and 9.0.1
have been released (May 6th).
## Summary
There is a bit of strange behavior with how Renovate parses some rules
because everything is disabled at first. Eng-Prod dug into this and this
was the recommended solution - having a rule just to enable
`chromedriver` and a second rule with our config. See
[Slack](https://elastic.slack.com/archives/C07AMD4CNUR/p1746479094816819)
for full context.
Closes https://github.com/elastic/kibana/issues/205531Closes#219877.
Closes https://github.com/elastic/kibana/issues/213153
Closes https://github.com/elastic/kibana/issues/150920
Closes https://github.com/elastic/kibana/issues/203130
### Overview
The embeddable framework has two types of state: `SerializedState` and
`RuntimeState`.
`SerializedState` is the form of the state when saved into a Dashboard
saved object. I.e. the References are extracted, and state saved
externally (by reference) is removed. In contrast `RuntimeState` is an
exact snapshot of the state used by the embeddable to render.
<b>Exposing SerializedState and RuntimeState was a mistake</b> that
caused numerous regressions and architectural complexities.
This PR simplifies the embeddable framework by only exposing
`SerializedState`. `RuntimeState` stays localized to the embeddable
implementation and is never leaked to the embeddable framework.
### Whats changed
* `ReactEmbeddableFactory<SerializedState, RuntimeState, Api>` =>
`EmbeddableFactory<SerializedState, Api>`
* `deserializeState` removed from embeddable factory. Instead,
`SerializedState` is passed directly into `buildEmbeddable`.
* `buildEmbeddable` parameter `buildApi` replaced with `finalizeApi`.
`buildApi({ api, comparators })` => `finalizeApi(api)`.
* The embeddable framework previously used its knowledge of
`RuntimeState` to setup and monitor unsaved changes. Now, unsaved
changes setup is pushed down to the embeddable implementation since the
embeddable framework no longer has knowledge of embeddable RuntimeState.
### Reviewer instructions
<b>Please prioritize reviews.</b> This is a large effort from our team
and is blocking many other initiatives. Getting this merged is a top
priority.
This is a large change that would best be reviewed by manually testing
the changes
* adding/editing your embeddable types
* Ensuring dashboard shows unsaved changes as expected
* Ensuring dashboard resets unsaved changes as expected
* Ensuring dashboard does not show unsaved changes after save and reset
* Returning to a dashboard with unsaved changes renders embeddables with
those unsaved changes
---------
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
Co-authored-by: Nathan Reese <reese.nathan@elastic.co>
Co-authored-by: Nick Peihl <nick.peihl@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: Catherine Liu <catherine.liu@elastic.co>
Co-authored-by: Ola Pawlus <98127445+olapawlus@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/38277
This PR ~attempts to take a stab at automating~ automates the process
for building the linux headless chromium used for reporting within
Kibana.
The Idea here is that one would simply only need create an issue within
the Kibana project that will then trigger the build for chromium, we'll
be leveraging GitHub actions for this, the Github workflow defined only
kicks in when an issue is created with the label
`trigger-chromium-build`, when such an issue is created, the body of the
issue is analysed; there's an expectation that the body would contain a
fenced codeblock of type json that specifies the property
`puppeteer_version`, if this is found this value is read and, we then
trigger a build on buildkite passing along this value, in the case where
there are multiple fenced code blocks specifying the expected property
`puppeteer_version` we leave a message that the issue body be modified,
also if the expected label was added but the expected property is not
found we also leave a message prompting that the expected property be
provided.
Once the build has commenced a message containing the link to the build
would be provided as initial feedback to the user, also on completion
another message is provided to the user, that provides a link to the PR
containing all the required changes to update puppeteer to the version
specified.
~It's also worth pointing out that this PR also, modifies the source for
`win`, `mac` chromium binaries to leverage the [JSON API
endpoint](https://github.com/GoogleChromeLabs/chrome-for-testing#json-api-endpoints)
provided by Google to get the required binaries for chromium headless in
a deterministic way, which in turns is part of what makes this
automation possible.~
## How to test this
- If you'd love to test the Github action too without the PR being
merging in just yet, you should consider setting up
[act](https://github.com/nektos/act), alongside it's companion [vscode
extension](https://sanjulaganepola.github.io/github-local-actions-docs/)
, we'll then want to create a payload file providing similar data that
github would return for our workflow trigger, more info about setting
this up
[here](https://sanjulaganepola.github.io/github-local-actions-docs/usage/settings/#payloads).
The payload file we'd want would be something along the following lines;
```json
{
"action": "labeled",
"label":{
"name": "trigger-chromium-build"
},
"issue": {
"number": 1,
"title": "Issue 1",
"author_association": "MEMBER",
"labels": [
{
"name": "trigger-chromium-build"
}
],
"body": "\n## Random text \n\n ~~~json\n{\n \"puppeteer_version\": \"24.6.1\" \n}\n~~~\n~~~json\n{\n \"some_random_value\": \"23.0.1\" \n}\n~~~"
}
}
```
- To test the actual build process it can be initiated through this
specific pipeline
https://buildkite.com/elastic/kibana-migration-pipeline-staging by
creating a custom build on `pull/212674/head` (this pull request) with
the env variable similar to this
```
TESTED_PIPELINE_PATH=.buildkite/pipelines/chromium_linux_build/build_chromium.yml
PUPPETEER_VERSION=24.6.1
GITHUB_ISSUE_NUMBER=212732
GITHUB_ISSUE_BASE_OWNER=elastic
GITHUB_ISSUE_BASE_REPO=kibana
GITHUB_ISSUE_TRIGGER_USER=eokoneyo
```
PS: Issue #212732 is an issue that's been created to test providing
feedback to the user about the build process, re-triggering a build on
an existing issue updates the comments in place.
<!-- ### Where to go from here?
- Ideas and thoughts welcome
-->
<!--
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] 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 was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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
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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/214448
As part of the Traces in Discover feature we want to add latency
duration chart to the already existing duration section.
### Details
- Created `latencyOverallSpanDistributionRoute` based on
`latencyOverallTransactionDistributionRoute` to gather the data needed
for rendering the span chart.
- We may reconsider whether this should remain in APM or be moved to a
shared package for better typing, easier exposure, and easier
maintenance. There's an
[issue](https://github.com/elastic/kibana/issues/216959) to address
this.
- Split `TraceDocumentOverview` into `TransactionDocumentOverview` and
`SpanDocumentOverview`, and also split `getTraceDocumentOverview` into
`getTransactionDocumentOverview` and `getSpanDocumentOverview`.
- Created `DurationDistributionChart` in `kbn-apm-ui-shared` based on
the `DurationDistributionChart` in APM.
- Keep in mind that it's an exact clone of the component and its
dependencies, excepting a couple of booleans I added as props, so I
don't expect any of it to be reviewed as part of this PR
- We'll be removing the APM version in favor of this one as part of this
[issue](https://github.com/elastic/kibana/issues/211781), so it only
exists in one place.
- Removed the telemetry TODOs since the issue was closed, and no
additional work is needed for tracking click links.
Both spans and transactions will now have the latency duration chart:
|Details||
|-|-|
|Transaction||
|Span||
|Loading||
|Dark mode||
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Make sure your space has Observability as Solution View.
- Open Discover and select or create a data view that includes any APM
traces index (`traces-*`), or query them using ES|QL.
- Apply a filter for `data_stream.type:"traces"` to ensure only trace
documents are retrieved.
- Open the flyout.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/216316
## Summary
This PR adds schema changes and validation for sending attachments with
the email connector. The connector email services uses the execute API
that bypasses task manager and just passes the attachments.
### Checklist
- [ ] [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
