This PR upgrades Puppeteer version to v24.10.1.
Tested locally, works as expected:
<img width="968" alt="Screenshot 2025-06-14 at 02 28 49"
src="https://github.com/user-attachments/assets/52ede4a6-d342-45f6-9fdf-5a01ce77fb47"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com>
Co-authored-by: Alexandra Doak <alexandra.doak@elastic.co>
## Summary
Legacy actions context: https://github.com/elastic/kibana/issues/112327
This PR modifies legacy SIEM action migration logic to migrate actions
in bulk, significantly improving performance. Response time and # of
requests to ES for SIEM rule management HTTP APIs are both significantly
reduced. When tested on 800 rules, this saves about 1-1.5 seconds per
bulk API call and eliminates hundreds of individual requests to
Elasticsearch. Bulk disable for example goes from taking ~3.3 seconds to
~2.3 seconds, and the APM transaction for the API call no longer drops
spans due to hitting the max span limit.
## Testing
I added a helper function in the quickstart tooling,
`createRuleWithLegacyAction`, to make it easier to get started with
manual testing. The function creates a connector, a rule, and then a
legacy action referencing the connector and the rule. The legacy action
(a `siem.notification` type rule) and rule can be viewed in the alerting
SO index via dev tools:
```
GET .kibana_alerting_cases/_search
{
"query": {
"bool": {
"filter": {
"term": {
"type": "alert"
}
}
}
}
}
```
Viewing the rule details via the Security Solution UI should display
only one rule with the action as part of the rule. After making any kind
of change to the rule (enable, disable, update, etc), the dev tools
command above should show only a single rule with the action inside the
rule instead of as a separate `siem.notification` type rule.
---------
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
PR adds migration of Response Actions and Artifacts when the space
awareness feature flag is enabled. Changes include:
- New saved object type (`security:reference-data`) to keep internal
data/information used by security solution. Currently being used to keep
migration state for both the Artifacts and Response actions migrations
- Two records will be populated in this new saved object related to the
migration being introduced here:
- ID: `SPACE-AWARENESS-ARTIFACT-MIGRATION` - keeps state information
about migration of Artifacts (see below for example)
- ID: `SPACE-AWARENESS-RESPONSE-ACTIONS-MIGRATION` - keeps state
information about migration of response actions (see below for example)
- NOTE: my goal was to also introduce a `client` for working with
internal reference data, but due to timing constraints, that will be
done at a later time
- Adds migration for Endpoint artifacts (Trusted applications, Event
filters, Blocklists, Host isolation exceptions and Endpoint exceptions)
to add the `spaceOwnerId:default` to all artifact records
- Adds migration for Response Action Requests (both Elastic Defend and
external EDRs) to populate `originSpaceId` as well `agent.policy.*`
fields.
- NOTE: when populating the `agent.policy.*` data, it may be possible
that the agent that the response action was sent to is no longer
available (ex. unenrolled). In such cases, the migration will populate
any field that it is not able to retrieve information for with the text
`MIGRATION:NOT-FOUND`
> [!IMPORTANT]
> The migration currently assumes that the `9.1.0` endpoint package is
already installed, which will not be the case with a real migration. To
test this PR, you should start a 9.1 stack with the feature flags
disabled... Install the `9.1.0` endpoint package, and then enable the
feature flags.
> We will be working on a solution handling this data condition in a
subsequent PR
Handles :
- https://github.com/elastic/security-team/issues/12236
- https://github.com/elastic/security-team/issues/12012
- https://github.com/elastic/security-team/issues/12235
## Summary
This PR adds the ability to change rule migration execution settings
when `re-processing` a migration. Now users can change :
- `connector` they want to use for this particular occasion.
- whether `prebuilt rules` should be matched or not.
This PR include below changes:
### Changes to `Re-process` workflow
Previously, clicking on `Reprocess Rules` would automatically start the
migration on the Translated Rules Page.
This has been changed to add the ability for user to change the settings
when starting the migrations can be seen below :
> [!Note]
> Sample Graph executions with `skipPrebuiltRulesMatching == true` can
be found
[here](66aedda3-8cfd-4eee-950d-7ba2f93a317e?timeModel=%7B%22duration%22%3A%227d%22%7D&searchModel=%7B%22filter%22%3A%22and%28eq%28is_root%2C+true%29%2C+and%28eq%28metadata_key%2C+%5C%22skipPrebuiltRulesMatching%5C%22%29%2C+eq%28metadata_value%2C+true%29%29%29%22%2C%22searchFilter%22%3A%22eq%28is_root%2C+true%29%22%7D&runtab=2)
https://github.com/user-attachments/assets/73c22157-f688-410d-852d-aff7be612771
### Changes to `/start` API
As can be seen below `connector_id` and new option
`skip_prebuilt_rules_matching` have been combined into a single
`settings` object.
#### Before
```ts
POST /start
{
"connector_id": boolean,
"retry": string,
"langsmith_options": {
"project_name": string,
"api_key": string
}
}
```
#### After
```ts
{
"settings": {
"connector_id": string,
"skip_prebuilt_rules_matching": boolean
},
"retry": string,
"langsmith_options": {
"project_name": string,
"api_key": string
}
}
```
### Changes to `rules/{migration_id}/stats` and `rules/stats` Endpoints
Now both `stats` and `stats_all` endpoints include migration's
last_execution details.
### Changes to Langsmith Graph
A new [run-time
config](https://v02.api.js.lang.chat/interfaces/_langchain_core.runnables.RunnableConfig.html#configurable)
called `skip_prebuilt_rules_matching` has been added to the graph which
does 2 things
- conditionally skips the `matchPrebuiltRule` node as can be seen by
graphs below
- Assigns a default `prebuilt_rule_id` of `null` in the
`translationResult` node.
### Re-processing `STOPPED` migrations
Previously we used to automatically reprocess `STOPPED` migrations with
the default `connector_id` selected by the user in `Siem Migrations`
Now, we first try to inherit the `last_execution` settings to re-start
the migration as can be seen
[here](https://github.com/elastic/kibana/pull/222542/files#diff-fa4ce089bfa7b6afec449c289c817f03eb074ae5ffcae828434255c800d9a9a2R287).
If not present, for example, for old migrations before this PR was
merged, then we use stored/default values.
### 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
- [ ] 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)
- [ ] ...
Simplify `FunctionVisibility` to only two possible states: `internal`
and `all`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/223170
Closes https://github.com/elastic/kibana/issues/223168
PR does the following:
* Removes `injectReferences` from `loadDashboardState`
* `type` and `id` are populated from matching panelRef server side with
dashboard api transform.
* Dynamic action `inject` is run during embeddable bootstrapping as part
of `initializeEmbeddableDynamicActions`.
* Removes `extractReferences` from dashboard `getSerializedState`
* extracts panelRef in `layoutManager.serializeLayout`
* Dynamic action `extract` is run during `embeddable.serializeState`
* Updates embeddable implementations that use
`initializeEmbeddableDynamicActions` to serialize dynamic action state
with references in `serializeState`
* Removes `PersistableStateService` from `EmbeddableStart` contract
* Moves `embeddable.common` `PersistableStateService` code to
`embeddable.server`
The PR is all ready large, so the following TODOs will be addressed in
follow on work
* Move `embeddable_enhanced` plugin to package.
* Clean-up dashboard/common folder, moving
src/platform/plugins/shared/dashboard/common/dashboard_container/persistable_state/dashboard_container_references.ts
and
src/platform/plugins/shared/dashboard/common/dashboard_saved_object/persistable_state/dashboard_saved_object_references.ts
functionality to server folder. The plan will be to break these files
into `inject_references` and `extract_references`.
### Embeddable owner test instructions
* open dashboard with panel type and drilldown. Verify drilldown works
as expected
* Create new dashboard with panel type and drilldown. Save dashboard.
Open dashboard and verify drilldown works as expected.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Removes the tech preview designation from the session invalidation API.
Resolves https://github.com/elastic/kibana/issues/224070
## Release Note
The Session Invalidation API is now marked as Stable.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR guards changes to the streams state that go through
`State.attemptChanges` via the newly introduced lock manager.
If two requests are happening at the same time, one of them now fails
with a 409.
## Concerns
* Lock expiry is 30s for now - is this too little? Should be good enough
for now, maybe we need to reconsider once we introduce the bulk api
* This is only guarding changes that go through the `State` class - some
things like queries and dashboards do not, so they can still be subject
to race conditions. We could sprinkle more locks over the code base, but
I would like to solve this by moving them into `State` as well, that
seems like the cleaner approach, even though a bit more effort
* Biggest question - on this PR the concurrent request fails directly
with a 409. Is this OK or should it wait and retry a couple times? I'm
in favor of starting like this and seeing if this is actually a problem.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kevin Lacabane <kevin.lacabane@elastic.co>
## Summary
Closes#221607
Improves naming of new tabs, so instead of determining number in tab
name as `tab count + 1` we now check the highest existing number on
default tab and add +1.
**Possible improvements:**
This logic is very similar to `onDuplicate` function, which lives in
`src/platform/packages/shared/kbn-unified-tabs/src/components/tabbed_content/tabbed_content.tsx`.
It may be worth to make it more DRY, I'm open for creating a new ticket
for this and handling it, if we agree on refactor. Or to handle it
within this PR.
My rough idea was to add a parameter to `createTabItem` which tells us
if we duplicate an item or not. If so, we should use a logic and regexes
similar to `onDuplicate` function, otherwise logic and regexes from this
PR. It adds `isDuplicate` parameter though in couple different places
causing prop drilling, so I hesitated with taking this decision on my
own.
**EDIT**
Created a new issue for extracting common parts [[OneDiscover][Tabs]
Extract common parts in creating and duplicating tabs
label](https://github.com/elastic/kibana/issues/223899#top)
### 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)
- [ ] ...
## Summary
Resolves https://github.com/elastic/streams-program/issues/292
This PR shows the streams description below its name using an InlineEdit
component.
I had to pass the refreshDefinition function in the tabs/dashboard and
use it whenever we update the list of dashboards since I had an issue
with using the outdated definition in case we updated the dashboards
list without fully refreshing the page.
https://github.com/user-attachments/assets/2e742263-a9d1-447a-9222-4b2c33d79958
---------
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Fixes https://github.com/elastic/kibana/issues/221820
Fixes https://github.com/elastic/kibana/issues/220879
## Summary
This PR reverts https://github.com/elastic/kibana/pull/204296 and
https://github.com/elastic/kibana/pull/218853 as these PRs caused issues
in the UI due to limitations in the Query Watches API. Therefore, we are
temporarily reverting back to fetching watches through the `.watches`
system index until we have better support from the Query Watches API.
**How to test:**
1. Start Es with `yarn es snapshot --license=trial` and Kibana with
`yarn start` (no need to test in serverless as Watcher is not available
there.
2. Navigate to Stack Management -> Watcher and create multiple watches
(the more, the better). Make sure you create watches of different types
(advanced/json or threshold), watches with or without names, etc. There
are different watches and use cases described in the
[documentation](https://www.elastic.co/docs/explore-analyze/alerts-cases/watcher).
Also, adding sample data sets is helpful so that you can get watches to
execute and have values under the "Condition last met" and "Last
checked" columns.
3. After creating various watches, open the table with watches and make
sure that all functionalities work correctly. For example:
- All watches are displayed, check with >10 watches and different page
sizes.
- Sorting works for all columns.
- Search bar works as expected and searching by partial id is supported.
- Deleting watches updates the table correctly.
https://github.com/user-attachments/assets/d0da9c24-7389-481d-8a16-a0d01bda0e80
## Release notes:
This update resolves multiple issues in Watcher UI that were introduced
in 8.18.0, 8.18.1, 9.0.0, and 9.1.0, including the table not displaying
more than 10 watches, an error banner appearing unexpectedly in certain
scenarios, and the search bar functionality not working as expected.
This PR removes the painless implementation of log document
normalization and switches to the Elasticsearch version which is meant
as the source of truth.
This shouldn't change behavior at all.
## Summary
### Test track
This is an entity that offers an easy way to distribute test loads to
run in parallel by assigning them to lanes. The main metric used to
determine on which lane of a test track a test load should go is
*estimated runtime*.
Other than load routing functions, the track itself doesn't hold any
logic that pertains to the distribution strategy. In the current
implementation, you can:
- add new lanes
- add a load to a new lane
- add a load to a lane based on it's current capacity
The test track also offers an easy way to serialise the specification,
which holds all relevant information that describes how the load is
distributed across lanes, along with some useful stats about the lanes
and the combined runtime.
Notes:
- A lane's capacity is represented by the difference between the current
estimated runtime and the target runtime
- If a lane's capacity has been reached or exceeded, the lane status
becomes `closed`
- If a lane's expected runtime exceeds the target runtime, the lane is
considered **congested**
### Test config stats
By querying Scout test event data collected from previous runs, we can
gather knowledge about each individual test config duration which is
crucial when deciding how we distribute the test loads to run in
parallel.
The following duration aggregations are recorded when test config stats
are collected: `avg`, `median`, `95th percentile`, `99th percentile`,
`max`.
The `95th percentile` value is what's currently used as the estimated
runtime.
### CLI: `scout update-test-config-stats`
Used to fetch the latest test config stats from Scout test events stored
in an Elasticsearch instance and store them locally under
`.scout/test_config_stats.json`.
This assumes that the test events used to calculate the stats have been
collected from Buildkite.
### CLI: `scout create-test-track`
Given a list of test config manifests, it distributes the enabled
configs on a test track and outputs the track specification to a file.
The estimated runtime for each config is determined from the test config
stats stored under `.scout/test_config_stats.json`.
The _target runtime_ of the track and _maximum lane count_ are
configurable to provide some flexibility depending on the use case.
If stats for a config are not available, the estimated runtime will
default to the target runtime of the track, effectively placing the
config on a separate lane, if the maximum lane count hasn't been already
reached.
#### Distribution strategy
- sort all test loads in descending order based on estimated runtime
- assign each load to the least loaded lane
- open a new lane no open lanes are available or adding it to an
existing lane would lead to congestion
This strategy is fairly basic, but it's pretty effective. It prioritises
maximum lane saturation and avoids lane congestion.
#### Example usage
Distribute stateful configs on a test track
```shell
node scripts/scout.js create-test-track \
--configManifest $(echo .buildkite/*_stateful_configs.yml | sed 's/ / --configManifest /g')
```
---------
Co-authored-by: Cesare de Cal <cesare.decal@elastic.co>
## Summary
- Forwards `startDate` correctly to the `CustomRecurringSchedule`
component. The missing prop caused the monthly custom frequency
sub-options to not show up.
- Fixes the `CustomRecurringSchedule` component type to correctly
reflect the required prop.
- Removes the `custom-recurring-form` data test subject from the
`<CustomRecurringSchedule>` JSX tag. The test subject wasn't forwarded
to any DOM element, but the only test with an assertion using that test
subject was passing because it was checking its absence
(`not.toBeInTheDocument()`).
## Verification steps
1. Open the Maintenance Window creation page
2. Toggle "Repeat" on
3. In the recurrence form, check that all the custom frequencies work,
showing the correct sub-options
## Summary
Improves the IF statement to ensure that we are dealing with an object
with loopable keys and remove the try-catch. If not loopable, we might
want to remove the user context entirely (or replace it with a known
object { id: '[INVALID]' }) since it might lead to APM traces being
discarded due to invalid user context.
closes https://github.com/elastic/kibana/issues/219095
## Summary
Closes https://github.com/elastic/kibana/issues/223007
### This PR fixes a couple of bugs in the visibility of the Alert Top
Nave menu item:
**1. When the user is in Classic space with <ins> no rule type
privileges </ins> the `Alert` top nav menu item should be hidden**
- Only `Discover` _**All**_ Feature Privilege
<img width="465" alt="Screenshot 2025-06-11 at 11 01 03"
src="https://github.com/user-attachments/assets/063a01b1-16a5-4ee1-b981-a2d4b93c08ac"
/></br></br>
**2. When a user has <ins> only `SLO` </ins> privilege the menu should
be shown with only SLO entry.**
- `Discover` & Observability `SLO` _**All**_ Feature Privilege
<img width="532" alt="Screenshot 2025-06-11 at 11 00 31"
src="https://github.com/user-attachments/assets/91f48791-28b0-48ce-b7fa-f1c8139556dd"
/></br></br>
**3. When the user has <ins> no `SLO` </ins> privilege, the `SLO` entry
should be hidden**
- `Discover` & Observability `Logs` _**All**_ Feature Privilege
<img width="518" alt="Screenshot 2025-06-11 at 11 01 34"
src="https://github.com/user-attachments/assets/c6df8a7d-c35b-43f0-be81-84ca3ef0b2e4"
/></br></br>
4. **When the user has access to <ins> only manage alerts </ins> without
specific rule type, the `Manage alerts` entry should be shown.**
- `Discover` & Security `Security` _**All**_ Feature Privilege in
**_Classic_** navigation
<img width="509" alt="Screenshot 2025-06-11 at 11 02 59"
src="https://github.com/user-attachments/assets/b5c370a6-f346-4bad-a8bd-d19fa6c95c76"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/220464
## Summary
As part of the EUI button style updates, I reviewed the RO files for any
CSS class overrides affecting `euiButton` and `euiFilter` components. I
found some custom CSS overrides and I was able to safely remove them.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Changes the dashboard endpoint routes from public to internal as they
are still unreleased.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/observability-dev/issues/4539
Fixes https://github.com/elastic/kibana/issues/221035
Enables custom roles for Observability projects in serverless.
The following is a summary of the changes:
## Feature renaming
1. Renamed `Uptime and Synthetics` to `Synthetics`
2. Renamed `APM and User Experience` to `Applications`
3. Renamed `Metrics` to `Infrastructure`
## Category reassignment
1. Changed `Dashboard` category from `Analytics` to `Observability`
2. Changed `Discover` category from `Analytics` to `Observability`
3. Changed `ML` category from `Analytics` to `Observability`
## Feature hiding
1. Hides the `Stack Alerts` feature.
2. Provides backwards compatibility for alerts created via Stack Alerts.
This enables our users to import rules created within Stack Alerts and
expect to see them in the Observability rules table.
## Navigation updates
1. Adds a `Custom Roles` link under the `Access` section in the
management navigation
2. Adds a `Manage Organization Members` link under the `Access` section
in the management navigation
3. Removes the `Users and Roles` link from the navigation footer (in
favor of the `Manage Organization Members link)
## Bug fixes
1. Fixes a bug where the `Alerts` link was not shown for Synthetics only
user (in stateful and serverless)
2. Fixes a bug where the `Alerts` link was not shown for Logs only user
(in stateful and serverless)
## Alert Override Removal
In the alerting framework, each rule is assigned a `consumer` value.
This `consumer` value changes depending on where the rule is created in
Kibana. However, in serverless we introduced an override that caused the
`consumer` value to be `Observability` in nearly every case. This logic
branched from stateful causing complexity and a large mental burden for
our engineers. Ultimately, this override became the source of bugs,
uncertainty, and unintended user experiences. Because of this, we've
removed this overrides.
If we kept this override, it would have the unfortunate side effect of
making all rules created in serverless visible from all custom roles (an
APM only user would have been can see Synthetics rules, and vice
versus). To make things more unpredictable, when users import their
rules from stateful the behavior would be different (access would be
properly mapped to the specific feature).
To address these specific user experience issues, and remove the source
of complexity, branching logic, and bugs, we removed this override logic
and restored the rule access behavior to match with stateful.
We did this while introducing backwards compatibility logic, ensuring
rules created in earlier versions of an oblt stateful cluster continue
to work and are accessible by a user with the right role access.
# Testing
1. Run local ES
```
yarn es serverless --projectType=oblt -E xpack.security.authc.native_roles.enabled=true
```
2. Run local Kibana
```
yarn start --serverless=oblt --xpack.security.roleManagementEnabled=true --xpack.cloud.users_and_roles_url="https://test_users_and_roles_url"
```
3. Login to Kibana with the admin role. Navigate to the Custom Roles
page via the management navigation.
4. Create a custom role
5. Log out of Kibana
6. Log back in with your custom role. You can do so by typing the custom
role name into the mock saml auth
<img width="460" alt="Screenshot 2025-05-22 at 9 23 13 PM"
src="https://github.com/user-attachments/assets/8e7f659b-5fe9-4e74-8c57-b420467d309e"
/>
---------
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## Summary
Resolves#221428.
We noticed recently when we added the Investigation Guide that, if the
user edits the values in the guide using the edit flyout, the data on
the main page will not refresh when they submit.
This patch would add an `onUpdate` handler prop to the Header Actions
component that would enable it to trigger the refresh on the parent
component when the user submits the form in the edit flyout.
Example:
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12790))
With these changes we add attack discovery alerts deduplication. Right
now identical attack are being stored within the alerts index and to
filter duplicates out we will use the next approach:
1. Each alert will have a ID generated as a SHA256 of attack attributes:
list of SIEM alerts IDs and space ID
2. After LLM generates attack discoveries we would check whether the
attack alert with the ID that describes the attack based on the rule
above exists in the alerts index
3. If such an alerts exists we would drop the generated discovery
4. Otherwise, we would proceed with storing the attack discovery as a
new alert
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
```
## Summary
Resolves#221835.
Adds case links to the Alert Details status bar.
When there is exactly 1 case, the status bar displays that case's name
and links to the case detail page.
When there is more than 1 case, an additional link with the text `+N
cases` will render as well. This link simply sends the user to the Cases
overview page. We need improved filtering to allow the URL to pass a
series of case IDs to pre-filter the overview page to make the user's
landing experience better when using this feature.
If there is no linked case, the case links will not display anything.
## TODOS
Best not to review this until these are checked off.
- [ ] If the user utilizes the _Add to case_ feature of the detail page,
the cases shown in the status bar do not update. We should fix this
before merging.
- [ ] We should also ensure we have additional unit tests included for
the locator code 100% coverage, as it's a little tricky.
- [ ] We need unit tests for the links hook.
## Testing this PR
- Create three alerts.
- Do not attach the first one to any cases. Go to the detail page and
see that there is no case-related info displayed in the status bar.
- Attach the second alert to a case, and go to its detail page. See that
the case is shown in the status bar like `Case: {caseName}`.
- Attach the third alert to more than one case. Go to the detail page
and verify that the two links, `caseName` and `+ N more` are displayed
and that they function properly.
- Repeat this testing for a kibana with and without a basePath, and
across spaces, to ensure the locators are working correctly.
<img width="779" alt="image"
src="https://github.com/user-attachments/assets/f135bd1e-a0dc-45f2-a003-a375f7589cf0"
/>
## Summary
Closes https://github.com/elastic/kibana/issues/222555
Remove `confidence` and `is_correction` attributes from knowledge base
entry since they are no longer used.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Søren Louv-Jansen <sorenlouv@gmail.com>
Since all the usage-api configs in CP has an `enabled` param, I'd like
to add that to connector usage reporting task as well. So we can
enable/disable the feature via config.
I got this PR deployed to serverless and was able to see a request to
usage-api:
<img width="1301" alt="Screenshot 2025-06-10 at 22 03 38"
src="https://github.com/user-attachments/assets/57c628fe-55a5-4d10-a2c0-82021be86fad"
/>
## Summary
This PR adds support for context awareness across tabs, allowing each
tab to have a separate data source profile and set of document profiles,
while all sharing the same root profile. Supporting this involved a few
main changes:
- Split out a separate `ScopedProfilesManager` class from the main
`ProfilesManager` to support managing data source and document profiles
separately from the root profile.
- Add a `createScopedProfilesManager` method to `ProfilesManager` to
support instantiating separate `ScopedProfilesManager` instances, which
are stored per tab in `RuntimeStateManager`.
- Add a `ScopedProfilesManagerProvider` component to provide access to
the current `ScopedProfilesManager` instance wherever it's needed
(Discover, Single doc, Surrounding docs, and the Discover session
embeddable).
Since this PR adds yet another React context provider to Discover (can't
be provided via `RuntimeStateProvider` since `ScopedProfilesManager`
must be accessible outside of the main Discover app), a new
`DiscoverTestProvider` helper component has been introduced, rather than
copy/pasting `ScopedProfilesManagerProvider` throughout the Jest tests.
All existing Discover tests that rely on providers have also been
updated to instead use `DiscoverTestProvider`. This greatly simplifies
test setup by ensuring the correct providers are automatically rendered
based on the passed props. It's also much more future proof since any
changes to providers later on no longer require updating dozens of test
files, and instead only the shared `DiscoverTestProvider`.
There are some changes here that will require updates to the context
awareness docs, which will be handled as part of #217128.
Resolves#216488.
### Checklist
- [ ] 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)
- [x] 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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: #151493
**Description**
Ensure consistent screen reader announcements for errors when saving a
Dashboard with the "Create Tag" workflow.
**Changes Made**
Added the required` aria-invalid` attribute at the appropriate location
to support screen reader error announcements.
**Notes**
The original issue suggested setting `aria-live="assertive"`, but this
may not be necessary. Based on our current accessibility guidelines,
using `aria-invalid` is sufficient and aligns with best practices.
**Screen**
<img width="1434" alt="image"
src="https://github.com/user-attachments/assets/afe1416b-34d2-46b5-88c4-fcac6a1f4c86"
/>
## Summary
Resolves#212419.
In the Synthetics plugin, we are referencing the action connector form
provided for Email. The a11y audit noted that the `Cc` and `Bcc`
features on this form break the focus flow and make the page
inaccessible. This patch will apply `autoFocus` to the combo box
elements that get rendered when these buttons are clicked, thus allowing
screen reader and keyboard-only users to navigate the UI properly.
**NOTE:** you may see an example of the failure on the linked issue. I
have re-created the flow using VoiceOver and keyboard navigation and
included a GIF of it below.
## Example
This PR closes#221947.
https://github.com/user-attachments/assets/25beac10-5677-42ef-9544-b3ede0bf9fa1
The last part of the video is me trying to find the telemetry event
fired when clicking the button.
**Acceptance Criteria:**
- The list should appear on the Related Dashboards tab, under the Linked
Dashboards ✅
- Users should have the ability to add or "promote" a suggested
dashboard to the list of linked dashboards stored on this rule, in a
single click ✅
- We are collecting telemetry so that we know how many times users click
the button to promote a suggested dashboard to a linked dashboard ✅
---------
Co-authored-by: Dominique Belcher <dominique.clarke@elastic.co>
## Summary
Following the advice from Matuesz, Emotion Maintainer, this PR enables
Emotion’s speedy mode (`insertRule` instead of `<style>` tag injection)
in the development environment.
## Why?
We recently investigated an issue related to [Emotion’s style tag
bloat](https://github.com/elastic/kibana/issues/218340). It turned out
that the slowdown only affects development — in production, Emotion uses
`insertRule`, which is significantly more performant.
In dev, Emotion injects a new <style> tag for each rule to improve DX,
but this can lead to major slowdowns, especially when rendering many
components. Speedy mode avoids that by using `insertRule`, which has
been measured to be even >10x faster.
### Why now?
The original reason for disabling speedy mode in dev (inability to
inspect/edit styles) is no longer a limitation in modern browsers
(Chrome, Firefox).
The slowdown in dev doesn’t reflect real prod performance, making it
harder to reason about actual bottlenecks. It also makes some of the
devs worried that Kibana performance is worse than it actually is on
prod.
### What's the degugging difference?
https://github.com/user-attachments/assets/58d911a7-e621-4144-8f1f-8b43101c44e2
The difference is that you can’t see the styles in the DOM or the
stylesheet (see the video), neither the source maps for styles. You can
still edit them in the dev tools, but clicking the source link takes you
to an empty style tag. I don’t see that as a big problem - styles are
still easy to find in the code since the files containing them are part
of the auto-generated classnames.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
