Depends on https://github.com/elastic/kibana/pull/221610
This PR adds the import index workflow to privileged user monitoring and
API changes required to support it.
### API Enhancements
* **New API for privilege monitoring index creation**: Added a new API
endpoint (`PUT /api/entity_analytics/monitoring/privileges/indices`) to
create indices for privilege monitoring with support for `standard` and
`lookup` modes. This includes the implementation of request and response
schemas (`create_indidex.gen.ts`, `create_indidex.schema.yaml`).
[[1]](diffhunk://#diff-68329bb90dea945f343e1637990d5d05bc159e0aa2511ef1e45d37ed1a6cda51R1-R41)
[[2]](diffhunk://#diff-e979499654a27b3c1930d63c5b1002113c1c3f53f84ce27a4d75a5c492717a96R1-R42)
* **Updated privilege monitoring health response**: Modified the health
response schema to include a `status` field and an optional `error`
object for detailed error handling
(`privilege_monitoring/health.gen.ts`,
`privilege_monitoring/health.schema.yaml`).
[[1]](diffhunk://#diff-00f39a3e65a336eaddf7d3203d1370d910f5ecd2062b6cc21d9c06922c12884eR19-R28)
[[2]](diffhunk://#diff-83afa72b7a1fc48f3cc063e9fb855190d3525228bc0488fb8b871e112b90e961L22-R33)
### Frontend Integration
* **Introduce the create index modal that opens when the create index
button is clicked.
* **Onboarding modal improvements**: Updated the `AddDataSourcePanel`
component to handle index creation more robustly by passing callbacks to
the modal (`add_data_source.tsx`).
* **Error handling in UI**: Enhanced the `PrivilegedUserMonitoring`
component to display error callouts when privilege monitoring data fails
to load (`privileged_user_monitoring/index.tsx`).
[[1]](diffhunk://#diff-273ad32c97dcf15c6c6054fd7c5516d587132674578d25986b235cd174c75789R22-R26)
[[2]](diffhunk://#diff-273ad32c97dcf15c6c6054fd7c5516d587132674578d25986b235cd174c75789R38-R51)
### How to test it?
* Go to the priv mon page with an empty cluster
* Click on the data source by the index button
* Search for available indices, it should return indices with
`user.name.keyword` fields
* Click 'create index' and create a new index
* Choose the created index and click 'Add privileged users'
* You should be redirected to the dashboard (The API is currently not
working)
### 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)
- [ ]
[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
- [ ] 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
- [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)
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Implements #213020
Partially implements filter bar seen with #213015
This PR adds a callout on the alert details page to encourage users to
visit the related alerts page when at least one alert was triggered
within 30 minutes of the current alert. If no alerts were triggered, the
message remains without a call to action.
https://github.com/user-attachments/assets/23b2d3e9-353b-45e1-a007-d188db5617fc
## Testing
The related alert query usually find alerts that were raised within a
day of each other. To find alerts that were raised within a few minutes,
try creating an SLO with a chosen groupBy field that will easily violate
a burn rate rule. Alerts should be triggered for each instance within
seconds. Once the filter is executed, these alerts should appear without
alerts that were triggered earlier in the day.
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR adds `kbn/cypress-test-helper` as platform shared package to
replace invalid imports from private `security-solution` plugin in
platform shared plugin `osquery`.
The reason is that we are **currently blocked with x-pack relocation due
to circular dependency**, e.g. in
https://github.com/elastic/kibana/pull/223897
```
info starting [tsc] > node_modules/typescript/bin/tsc -b tsconfig.refs.json --pretty
--
| 2025-06-13 13:17:30 UTC | proc [tsc] error TS6202: Project references may not form a circular graph. Cycle detected: /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/tsconfig.refs.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/platform/plugins/shared/osquery/cypress/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/test_serverless/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/solutions/security/test/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/test/security_solution_endpoint/tsconfig.type_check.json
```
**Important:**
This PR focuses only on replacing test helpers imports from
`@kbn/security-solution-plugin` and `@kbn/test-suites-xpack` in
`osquery` plugin, no code cleanup and updates in other plugins / test
packages.
We expect code owners to update other imports / refactor package to
avoid code duplication
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## Summary
### What is included?
* Improves the auth dashboard to display system events
* Add data view index patterns as visualisations index
* Move ESQL query generation to a shared folder
* Parse ESQL query and validate if fields exist in the dataview
* Rewrite the ESQL query if a FORK command has missing fields
* Add a visualisation warning message when there is no valid FORK branch
### Pros
* To be able to render parts of the query depending on whether indices
or fields exist in the cluster
* The queries become much easier to read, maintain and fix
### Cons
* We need to test the performance
* FORK is in tech preview
* The commands we can use in a fork are limited to “WHERE, LIMIT, SORT,
EVAL, STATS, DISSECT”
### How to test it?
* Open the dashboard without privmon data, some of the visualisations
should display the warning message
* Add privmon data, the visualisation should display the data
(https://github.com/elastic/security-documents-generator/pull/163)
* Check if the visualisation displays the correct data.
* To test if the FORK rewrite logic is working, I update the queries on
my local environment to use a non-existent field and update the page.
### 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
- [ ] 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
Objective: avoid exposing the entire API surface area of `HttpService`
(and it's internal preboot/setup/start contracts) to test code outside
core.
* Refactor the `createHttpService -> createInternalHttpService` mock
test helper moved to scoped folder
`./src/core/server/integration_tests/utilities`
* Create an "integration test ready" version of the original
`createHttpService` for plugins to use from
`@kbn/core-http-server-mocks`
* Clean up some types
* Refactor the 2 plugin test usages of the internal `HttpService`
### Notes
* We have been exposing this surface area already in
`src/core/packages/http/server-mocks/src/http_service.mock.ts`. But it
seems to not have a adoption outside Core code... I wonder if we need a
concept of `mock-internal`?
* I don't think this is a **massive** issue, I just happened to realise
this when [messing
around](https://github.com/elastic/kibana/pull/222956) with an
`HttpService` related refactor. Would be nice to not leak more
information about internal code than necessary (it's clearly too late
for that, but maybe we can improve the situation for HttpService a bit).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
When checking the Overview cluster, I noticed that we previously had
`labels.error_type` in APM. In this PR, I changed the label that I've
added in the following PRs for fatal react errors and toast errors to
use `labels.error_type` instead of `labels.errorType` for consistency.
- Toast error: https://github.com/elastic/kibana/pull/217948
- Fatal react error: https://github.com/elastic/kibana/pull/218846
## Summary
Prior to this change, with data view manager feature flag enabled, we
would only see the "expand" cell action in the alerts. Now,
all the actions should be visible. This was because cell actions
rendering was unintentinally omitted in the initial batch of changes
that added data view sourcing from the new store / hooks.
fixes https://github.com/elastic/security-team/issues/12853
### Testing
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
then navigate to alerts page, hovering on timeline cell for example
should render full set of hover actions.
### 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
Filters we applied but no listed in the timeline, again - some mismatch
in how the data view object was passed around.
## Testing
Set the feature flag:
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
Then, adding a filter via cell action should render the correct pill in
the top level filters pane.
### Checklist
Check the PR satisfies following conditions.
- [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
Recently, an alarm was fired in the Kibana Serverless Slack Channel due
a problem with Data Usage. Issue explanation:
> Kibana's data_usage plugin allows collecting misc stats about Kibana
usage.
> The browser side performs requests to /internal/api/data_usage/*,
providing stats related to the user interaction with the UI.
> Recently, in an internal customer project, on production, one of these
requests (POST /internal/api/data_usage/metrics) contained a payload
that was deemed invalid by the server-side validation logic.
>
> The handler on that endpoint logged an error message.
> This error message was spotted by a Rule.
> Consequently, the rule fired an alert in our Slack channel.
>
> We shouldn't have invalid payloads coming from browser side, so unless
someone intentionally tampered with the HTTP request, this indicates a
bug in our browser-side logic.
> Customer Impact: This was an isolated error on an internal project,
but other folks within Elastic have spotted the same error message in
their projects. Due to that error, we might be missing a few data_usage
metrics.
The issue was caused because the plugin validation was waiting for an
array for the data property, but the payload from the API was returning
`null`. The validation was incorrect in the Kibana side since only
[name](https://github.com/elastic/autoops-services/blob/master/monitoring/service/specs/serverless_project_metrics_api.yaml#L189)
is mandatory.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR is for a feature branch that is being merged into main.
The relevant PRs are:
- https://github.com/elastic/kibana/pull/219211
- https://github.com/elastic/kibana/pull/222820
- https://github.com/elastic/kibana/pull/223241
- https://github.com/elastic/kibana/pull/224388
- https://github.com/elastic/kibana/pull/224682
## Summary
This PR adds 4 new indexes with case analytics data, which are created
when the cases plugin starts.
- `.internal.cases`
- `.internal.cases-comments`
- `.internal.cases-attachments`
- `.internal.cases-activity`
After the indexes are created, a backfill task for each of them is
scheduled to run 1 minute after creation. This task populates the
indexes with relevant data from `.kibana_alerting_cases`.
A second type of task is registered, the index synchronization task.
Four of these tasks, one for each index, are scheduled to run every 5
minutes. The synchronization tasks populated the indexes with data from
`.kibana_alerting_cases` that was created or updated in the last five
minutes.
## How to test
You might want to start Kibana with `--verbose` to see relevant index
messages in the console.
Alternatively(what I normally do), is go to `analytics_index.ts`,
`backfill_task_runner.ts`, and `synchronization_task_runner.ts`, and
change the `logDebug` function to call `this.logger.info` instead. This
way, you will have less spam in the console.
Every log message starts with the index name between square brackets, so
you can look for `[.internal.cases-` and follow what is happening.
1. You should have some existing case data, so before anything else,
please create some activity, attachments, etc.
2. Add `xpack.cases.analytics.index.enabled: true` to `kibana.dev.yml`
and restart Kibana.
3. Check out [this
branch](https://github.com/elastic/elasticsearch/pull/129414) from the
ES project.
4. Start Elastic Search with `yarn es source`. This will use the above
version of Elasticsearch.
5. Wait a bit for the indexes to be created and populated(backfilled).
6. Using the dev tools:
- Confirm the indexes exist.
- Check the index mapping. Does it match the one in the code? Is the
`_meta` field correct?
-
`x-pack/platform/plugins/shared/cases/server/cases_analytics/******_index/mappings.ts`
- Check that the painless scripts match the code.
-
`x-pack/platform/plugins/shared/cases/server/cases_analytics/******_index/painless_scripts.ts`
- Confirm your existing case data is in the indexes. (See **Queries**
section below.)
7. Play around with cases. Some examples:
- Create a case
- Change status/severity
- Attach alerts
- Add files
- Change category/tags
- Add comments
- etc
8. Go to the dev tools again and confirm all this shows up in the
relevant indexes. (See **Queries** section below.)
## Queries
In addition to the ones, below I have a few more. Things like reindexing
with specific scripts or fetching relevant data from
`.kibana_alerting_cases`. Ping me if you want those queries.
### Checking index content
```
GET /.internal.cases/_search
GET /.internal.cases-comments/_search
GET /.internal.cases-attachments/_search
GET /.internal.cases-activity/_search
```
### Checking index mappings
```
GET /.internal.cases
GET /.internal.cases-comments
GET /.internal.cases-attachments
GET /.internal.cases-activity
```
### Fetching the painless scripts
```
GET /_scripts/cai_cases_script_1
GET /_scripts/cai_attachments_script_1
GET /_scripts/cai_comments_script_1
GET /_scripts/cai_activity_script_1
```
### Emptying the indexes
It is sometimes useful for testing.
```
POST /.internal.cases/_delete_by_query
POST /.internal.cases-comments/_delete_by_query
POST /.internal.cases-attachments/_delete_by_query
POST /.internal.cases-activity/_delete_by_query
```
### Deleting the indexes
It is sometimes useful for testing.
```
DELETE /.internal.cases
DELETE /.internal.cases-comments
DELETE /.internal.cases-attachments
DELETE /.internal.cases-activity
```
## Release notes
Four dedicated case analytics indexes were created, allowing users to
build dashboards and metrics over case data. These indexes are created
on Kibana startup and updated periodically with cases, comments,
attachments, and activity data.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
## Summary
Issue reported by users that some unenrolled agents on the UI are not
being deleted by the background task.
The cause turned out to be a discrepancy in how unenrolled agents are
determined on the UI versus the background task.
The UI shows agents as unenrolled if `active:false` field matches (logic
[here](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/server/services/agents/build_status_runtime_field.ts#L115-L119))
The delete unenrolled agents task also queried on the existence of
`unenrolled_at` field.
It seems some agents don't have this field set, those should be deleted
too.
Integrating latest translations extracted from main branch.
Skipping backports from main to target branches since the `i18n_check`
might trim unused translations that are still used in different
branches. Integration script is ran against each target branch
separately.
## Summary
This PR customized Discover's Security Root Profile with 3 new changes.
\
With this change Discover's Security profile ceases to be
`experimental`. Below are the changes listed one in this profile.
>[!Note]
> This change also removes the Flyout changes that were added for
security solution to the Discover's security profile.
### Row Indicators.
Adds row indicators based on Alert or an event as shown in the
screenshot below. Note the highlights on the left of the row.
`Yellow` for Alerts.
`Gray` for Events.
### Default list of Columns.
Adds the list of default columns that should appear when security
profile is activated.
### Explore in Security Flyout.
As shown the demo below, this action explores and event or an alert in
security solution as shown in the screenshot below.
https://github.com/user-attachments/assets/4c228bb1-60af-433b-8e8f-1a5d4d049985
### 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/packages/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
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
This PR fixes some code paths/requests for calculating Duration
histograms and Trace summaries to account for unprocessed OTEL data. It
isn't the nicest way of doing things, because deep in APM, there is of
course an assumption that data is being dealt with in ECS format.
Probably longer term, this should be refactored, but this at least adds
in support for unprocessed OTEL for the duration widget.
Related to #221521
## How to test
* Add the following 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
```
* Set up a source of unprocessed OTEL data to feed into ES (Open
telemetry demo, etc)
* Set your space to Observability mode, and go to Discover.
* Query for `traces-*` and open any record for the document viewer
* The Span Overview waterfall should show the duration histogram that
match the document's formatted duration in the Table/JSON tabs, as well
as the trace summary information (trace id & span name)
---------
Co-authored-by: Milosz Marcinkowski <38698566+miloszmarcinkowski@users.noreply.github.com>
Closes: https://github.com/elastic/kibana/issues/220954
`fleet/remote_synced_integrations/<output-id>/remote_status` includes
non-http request errors in the error field of the status response for
improved client handling.
## Summary
Resolves#222051.
This PR makes a richer empty state UX for the Investigation Guide
feature we added to the Alert Details page.
Before, when a rule did not have an investigation guide, the tab on the
alert details page dedicated to the feature was disabled. Now, the tab
is always enabled. When an investigation guide is present on a rule, a
badge will display to indicate the tab contains content.
If the user clicks into the tab when the rule does not have an
investigation guide, they will see an empty state with a call to action
to create a guide. If the user decides to click the empty state button,
it will open the Rule Edit flyout. I have added additional functionality
that allows the flyout to take an `initialStep` prop, so we pre-set the
flyout to the `Details` step which contains the text field the user can
use to create their guide.
The copy, iconography, and layout of the tab heading are all in draft
state pending some design feedback. I will also add some tests to the
code that I have added.
## Reviewing this PR
_Note to technical writers:_ You can see the copy added for the empty
state
[here](https://github.com/elastic/kibana/pull/223974/files#diff-71b439414e4974e2decb0f25c136f52ccea4b49ebe393af68dfc5fd184d56e1cR37).
Here's a screenshot as well:
<img width="375" alt="image"
src="https://github.com/user-attachments/assets/491d87ac-b473-484e-82cd-45a1bd197c61"
/>
### Technical review
1. Create a rule that will generate alerts; _do not_ define an
Investigation Guide for it
1. Trigger an alert, and go to the details page
1. You should see the Investigation guide tab is available, whereas on
`main` it would be disabled
1. Open the Investigation Guide tab, you should see the empty state with
its CTA
1. Click this button, the rule flyout should open in Edit mode, and the
Details step should be pre-selected
1. Define an investigation guide, this can be any text. Save the rule.
1. Once you have saved the rule you should see the rule data update in
the page. The empty state will be gone and the investigation guide you
defined will be there instead.
## Summary 🌷
Resolves https://github.com/elastic/observability-dev/issues/4568
### Test Now flyout
Checked this by throwing an error within the flyout:
<img width="1584" alt="image"
src="https://github.com/user-attachments/assets/d8cfe96e-8b1b-4c28-819e-82411b5f20af"
/>
### Monitor detail flyout
In the case of this flyout, IMO, we should not use an error boundary. We
are receiving an error that has been caught and placed into the plugin's
Redux store, and then selecting that as part of the render procedure of
this component. Thus, we should display it using `EuiCallout`, which is
the recommended course per [the
docs](https://eui.elastic.co/docs/patterns/error-messages/error-banners/).
Example implementation below:
_note:_ all the copy here is placeholder and we should run it by our
tech writers.
<img width="607" alt="image"
src="https://github.com/user-attachments/assets/ef60258e-e50e-4fa7-adc5-b77469ddc0fb"
/>
We should not use an error boundary, as they are there specifically to
handle unforeseen errors that we can't account for at development time.
In this case, we have already caught the error and persisted it in app
state, so I don't think it's appropriate to display it in an error
boundary as the runtime is still progressing and is not broken.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes tab selection issue when user opens alert details page from
"Related alerts" tab. In this case, "Overview" tab should be selected by
default. In other cases, tab Id passed from URL should be used otherwise
default to "Overview".
## Summary
- Adds configuration for the product intercept in `oblt`, `es` and
`security` serverless offerings, alongsides stateful offering too. The
configuration provided sets the intercept to display every 90days, this
is configurable through the config `xpack.product_intercept.interval`.
The intercept can also be turned off through the config
`xpack.product_intercept.enabled`
- Also tweaks prompter timer implementation to accommodate inherent
[issue with long timer
delays](https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout#maximum_delay_value)
in the browser
- Adjusts the signature of the `registerIntercept` method, such that a
deferred value to be evaluated when the intercept is to be displayed is
passed. This unlocks the ability to have consumers provide dynamically
imported modules that provide the config for the intercept, see
0e07892217
for an example.
### How to test
- Add the following config to your `kibana.dev.yml` file;
```yml
xpack.product_intercept.enabled: true
# we set the interval to 30s so the wait long period to display the
intercept is bearable
xpack.product_intercept.interval: '30s'
```
- Start kibana in stateful, and serverless mode, in either scenario you
should be presented the product intercept, with the intercept
specifically stating the current product the user is interacting with.
See below for an example of observability solution;
https://github.com/user-attachments/assets/6ca6baf2-58d3-4002-ac94-ec6e9a0902ae
<!--
### 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>
Resolves https://github.com/elastic/kibana/issues/222104
## Summary
Adds optional flag when registering a rule type for "dangerously
creating alerts in all spaces". If a rule type opts into this flag,
alerts created during rule execution will persist the `kibana.space_ids`
field as `"*"` instead of the space ID of the rule. Note that we store
`kibana.space_ids` as a string array, so the final alert document will
have
```
'kibana.space_ids': ['*']
```
This PR just adds the flag and updates the code to respect the flag. It
does not opt any rule types into using it. You can look at the
functional tests to see example test rule types that use it.
Because the streams rule type that we expect to be the first user of
this flag uses the `persistenceRuleTypeWrapper` in the rule registry for
writing alerts, we also had to update the rule registry code.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Addresses a bug with the `ConnectorTokenClient` when using the
`UnsecuredActionClient` to execute actions directly (vs enqueuing a task
for execution). We previous pass in an internal saved objects repository
(that doesn't require a user request) to the `ConnectorTokenClient` when
using the `UnsecuredActionsClient` but this does not create the
`connector_token` saved object correctly so the next time it's read, we
get a `Failed to decrypt attribute` error.
This only occurs when using the `sendAttachmentEmail` with the MS
Exchange connector function added in this PR:
https://github.com/elastic/kibana/pull/219164. It does not affect the
other email service methods.
## To Verify
1. Ask me for MS Exchange credentials
2. Add this to your Kibana config:
```
xpack.actions.preconfigured:
test-exchange-email:
name: preconfigured-exchange-email
actionTypeId: .email
config:
service: exchange_server
clientId: <clientId>
tenantId: <tenantId>
from: <from>
secrets:
clientSecret: <secret>
notifications.connectors.default.email: test-exchange-email
```
3. Make this change to the code so Kibana sends 2 emails when it starts
up:
```
--- a/x-pack/platform/plugins/shared/notifications/server/plugin.ts
+++ b/x-pack/platform/plugins/shared/notifications/server/plugin.ts
@@ -40,6 +40,27 @@ export class NotificationsPlugin
public start(_core: CoreStart, plugins: NotificationsServerStartDependencies) {
const emailStartContract = this.emailServiceProvider.start(plugins);
+ const emailService = emailStartContract.getEmailService();
+ emailService
+ .sendAttachmentEmail({
+ to: ['<email>'],
+ subject: 'yo',
+ message: 'i am here',
+ attachments: [],
+ spaceId: 'default',
+ })
+ .then(() => {
+ new Promise((resolve) => setTimeout(resolve, 5000)).then(() => {
+ emailService.sendAttachmentEmail({
+ to: ['<email>'],
+ subject: 'yo',
+ message: 'i am here again',
+ attachments: [],
+ spaceId: 'default',
+ });
+ });
+ });
+
return {
```
4. Verify there are no decryption errors for the `connector_token` SO
logged and that the emails are sent successfully.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This is a farewell PR to Cases. Probably my last PR to the cases
codebase. It was quite a journey, and I learned a lot. I hope the best
for the feature of Cases.
## Decisions
Just before Cases was forbidden to do migrations, we did a last
migration to all cases to persist `total_alerts: -1` and
`total_comments: -1`. We did that so that in the future, when we would
want to populate the fields, we would know which cases have their fields
populated and which do not. In this PR, due to time constraints and
criticality of the feature, I took the following decisions:
- Cases return from their APIs the total comments and alerts of each
case. They do that by doing an aggregation, getting the counts, and
merging them with the response. I did not change that behavior. In
following PRs, it can be optimized and fetch the stats only for cases
that do not yet have their stats populated (cases with -1 in the counts)
- When a case is created, the counts are zero.
- When a comment or alert is added, I do an aggregation to get the stats
(total alerts and comments) of the current case, and then update the
counters with the number of the newly created attachments. The case is
updated without version checks. In race conditions, where an attachment
is being added before updating the case, the numbers could be off. This
is a deliberate choice. It can be fixed later with retries and version
concurrency control.
- The case service will continue to not return the `total_alerts` and
`total_comments`.
- The case service will accept the `total_alerts` and `total_comments`
attributes to be able to set them.
Fixes: https://github.com/elastic/kibana/issues/217636
cc @michaelolo24
### 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
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [papaparse](https://www.papaparse.com/)
([source](https://redirect.github.com/mholt/PapaParse)) | dependencies |
patch | [`^5.5.2` ->
`^5.5.3`](https://renovatebot.com/diffs/npm/papaparse/5.5.2/5.5.3) |
---
### Release Notes
<details>
<summary>mholt/PapaParse (papaparse)</summary>
###
[`v5.5.3`](e3c7b2628c...a4f8b0f1e3)
[Compare
Source](e3c7b2628c...a4f8b0f1e3)
</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:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOiBTZWN1cml0eVNvbHV0aW9uIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Marshall Main <55718608+marshallmain@users.noreply.github.com>
