## Summary
Hides security sub-privileges for ai4soc/search_ai_lake tier.
### Reasoning for changes added to `x-pack/packages/security`:
Currently, the feature description of Security feature is tied to the
fact that it has a list of sub-privileges. This is true on ESS and
`essentials/complete` serverless tiers.
With the introduction of the lower `search_ai_lake` tier, security
feature would not have any sub-privileges available and thus it does not
make sense to show that description.
The ideal way to handle this would be to load feature privileges config
settings at the plugin level
(security_solution/security_solution_serverless) and set `description`
to `null | undefined` based on the tier, as currently the feature
privileges settings live in [kibana_features file
(v2_features)](795094d8c6/x-pack/solutions/security/packages/features/src/security/v2_features/kibana_features.ts (L72))
(also another set in v1_features) and the plugins only select a set of
those based on the [feature keys
available](d4a33a2b61/x-pack/solutions/security/plugins/security_solution_serverless/common/pli/pli_config.ts)
on each tier. The refactoring to pass in feature configs at the plugin
level (instead of just feature keys) is not in the scope of the work cut
out for RSA conf.
Thus the other simpler approach in this PR is to allow overriding the
description field on the tier specific config file.
## How to Test
1. While on the Kibana root directory, run ES/Kibana on serverless mode
with:
```bash
yarn es serverless --kill --projectType security --kibanaUrl=http://0.0.0.0:5601
```
and on a new window
```bash
yarn serverless-security --no-base-path
```
Enable the AI for SOC tier, by adding the following to your
`serverless.security.dev.yaml` file:
```json5
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Once Kibana is up and running login in with the `admin` role using
the role dropdown.
3. Navigate to `app/management/roles/edit`
4. Click on `Assign to space` button and assign a space to that role on
the `Assign role to spaces` flyout.
5. Expand the `Security` category and verify that `Security` feature is
listed in the list of features.
6. Also verify that there is neither an accordion icon beside `Security`
feature nor a description text under it about sub-privileges.
### 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
Just had some fun and made fp-ts available in the shared bundle, with
support for partial imports.
Changes in this PR:
* aligned `fp-ts` direct imports to the format: `fp-ts/<module>`
* Mapped the direct imports into the shared bundle re-using the same
`fp-ts` module under the hood
## Summary
Redo of https://github.com/elastic/kibana/pull/193471
Closes https://github.com/elastic/security-team/issues/8644
> Fixes a bug where importing a rule fails with a connector into a space
where (1) the connector already exists, and (2) the existing connector
was exported and re-imported from another space. The import logic in
this scenario effectively tries to convert the action ID on the rule
import twice. The second conversion attempt tries to use the old action
ID to look up the correct new action ID in a map, however, in this test
scenario the action ID has already been updated by legacy SO ID
migration logic and there is no map entry with the new ID as a key. The
result is that the second attempt sets the action ID to undefined,
resulting in an import failure.
The root cause of the bug is that we have two different places in the
rule import logic where action IDs are migrated. The first ID migration
was done by `migrateLegacyActionsIds` prior to importing rule actions,
and the second migration was done by `importRuleActionConnectors` after
importing the actions. `importRuleActionConnectors` used a lookup table
to convert old IDs to new IDs, but if the connector already existed and
had an `originId` then the rule action would already be migrated by
`migrateLegacyActionsIds`. The lookup table used by
`importRuleActionConnectors` does not have entries for migrated IDs,
only the original IDs, so in that case the result of the lookup is
`undefined` which we assign to the action ID.
This PR reworks the logic to create a clean separation between action
and rule import. We now import the connectors first, ignoring the rules,
then migrate action IDs on the rules afterwards. This handles connectors
changing IDs in any way, either through the 7.x->8.0 migration long ago
or IDs changing on import if there are ID conflicts. Only after the
connectors are imported and rule actions are migrated do we then verify
if each rule action references a connector ID that actually exists with
the new `checkRuleActions` function, replacing
`checkIfActionsHaveMissingConnectors` and related functions that were
also buggy.
Finally, as a nice side effect this rework removes "rule action
connector missing" errors out of the `action_connector_errors` part of
the response. `action_connector_errors` is reserved for errors importing
connectors specifically. If a rule action is missing a connector and
therefore we don't import the rule, that's a rule error and it's
represented in the `errors` part of the response. Since the shape of the
response is not changing, I don't consider this a breaking change but
rather a bug fix.
## Repro Steps
Repro Steps
1. Download the export file below and change the extension back to
.ndjson from .json (github does not allow .ndjson files
[rules_export.json](https://github.com/user-attachments/files/17065272/rules_export.json)
2. Import the rule and connector into a space (default is fine)
3. Create a new space
4. Import the rule and connector into the new space
5. Import the rule and connector into the new space again, but check the
`Overwrite existing connectors with conflicting action "id"` box.
Observe the failure.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/208671
## Summary
Before this PR, the displayed index mode of the data streams was
determined based on the index mode of the associated index template.
However, the index mode can also be set through the component template,
so that logic is not reliable and can cause incorrectly displayed index
mode like described in https://github.com/elastic/kibana/issues/208671.
In this PR, we replace this logic with the recently added `index_mode`
field to the Es Get Data Streams API (see
https://github.com/elastic/elasticsearch/pull/122486).
**How to test:**
1. Create a component template with a LogsDB index mode (you can also
test with other index modes):
```
PUT _component_template/my-component-template
{
"template": {
"settings": {
"index": {
"mode": "logsdb"
}
}
}
}
```
2. Create an index template that is composed of the component template
above:
```
PUT _index_template/my-index-template
{
"index_patterns": [
"my-ds-*"
],
"data_stream": {},
"composed_of": [
"my-component-template"
]
}
```
3. Create a data stream that matched the index pattern from the index
template above:
```
PUT _data_stream/my-ds-1
```
4. Go to the data streams table and verify that the index mode is
displayed correctly in the table.
<img width="1165" alt="Screenshot 2025-03-24 at 18 12 04"
src="https://github.com/user-attachments/assets/ea211c14-3d03-49c7-ace7-88b15e294d1f"
/>
5. Click on the created data stream and verify that the displayed index
mode in the details panel is correct:
<img width="1165" alt="Screenshot 2025-03-06 at 14 36 12"
src="https://github.com/user-attachments/assets/954864e2-ae2a-4cb8-9eef-2c5f8b417f52"
/>
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/208025
This change deleted the "Stream log files" onboarding flow which is now
replaced by the Auto Detect flow.
| Before | After |
| --- | --- |
| 
| 
|
Changes made:
* Deleted UI components responsible for rendering the Custom Logs flow
* Deleted the definition for a custom card in the onboarding search
results
* Deleted API endpoints and supporting files used only by the Custom
Logs flow
* `/internal/observability_onboarding/logs/setup/environment` endpoint
was still used by the OTel Host flow, so it was moved to a dedicated
OTel route and pathname changed to
`/internal/observability_onboarding/otel_host/setup`
* Functionality of the `/internal/observability_onboarding/otel/api_key`
endpoint was merged into the above mentioned OTel route, so UI has to
make a single API request to get all the necessary information from the
server
* Deleted Scout UI tests for the Custom Logs flow
* Deleted API integration tests for the deleted endpoints
* API tests that we previously testing
`/internal/observability_onboarding/logs/flow` were converted to test
`/internal/observability_onboarding/flow'` used by the Auto Detect flow
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR fixes an issue that can cause test execution to fail when `await
kbnClient.status.get()` doesn't return the Kibana version. The fallback
now uses the version from `package.json` in that case.
Example failure:
https://buildkite.com/elastic/kibana-on-merge/builds/66520#0196344e-f27e-4ab8-9bf7-f041b94c665d/268-3998
---------
Co-authored-by: Patryk Kopyciński <contact@patrykkopycinski.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/199188
Allow multiple SAML authc calls to succeed.
## Testing
Configure logging:
```yaml
logging.loggers:
- name: plugins.security
level: debug
```
### See the failure
Pull `main` and copy the code from the following files in this PR into
their respective files on that branch:
- `packages/kbn-mock-idp-plugin/public/login_page.tsx`
- `packages/kbn-mock-idp-plugin/server/plugin.ts`
- `packages/kbn-mock-idp-utils/src/index.ts`
- `packages/kbn-mock-idp-utils/src/utils.ts`
Start KB/ES in serverless from this modified main branch
Open 2 tabs to the local serverless login screen
As the same user, click login and change tabs and click login again
The you will get an error.
Shut down KB/ES
### See the success
Start KB/ES in serverless from this PR
Open 2 tabs to the local serverless login screen
As the same user, click login and change tabs and click login again
Both should succeed
## Release note
Refreshing multiple tabs where the user has logged out will
simultaneously login successfully
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow-up to #217153
### Problem Description
In UI tests, there was no reliable way to determine when the Alerts
table content had fully loaded before interacting with it. This could
lead to flaky tests where interactions occurred before the data was
available (rows are not present yet), causing failures or inconsistent
results (checking for row with specific content to exist)
Quite often we see tests waiting for global indicator (spinner in the
top left corner) to be hidden as a condition for page loading is
complete. This is quite unreliable approach and testing tools have no
consistent built-in solution: FTR, Cypress or even Playwright - network
idle wait is officially marked as
[discouraged](https://playwright.dev/docs/api/class-page)).
We need to help testing tool to interact with UI components in ready
state only.
### Solution
To address this issue, I modified a `data-test-subj` property in the
`<EuiDataGrid>` component. The property dynamically switches between
`alertsTableIsLoading` when data is still loading and
`alertsTableIsLoaded `once the content is available. This allows UI
tests to wait for precisely `alertsTableIsLoaded` to be in in the DOM
before interacting with the table, ensuring more reliable and stable
test execution.
Passed 10/10
<img width="538" alt="image"
src="https://github.com/user-attachments/assets/e44bae5f-4094-4ed2-89f3-74a52cb2be53"
/>
## Summary
Introduce a new Entity Engine Definition called Generic. The larger
context on why we are introducing a new entity definition is described
on this [private github
issue](https://github.com/elastic/security-team/issues/11857).
The tldr; is that we would like to have an entity store with all the
entities described by the [entity ecs
field](https://github.com/elastic/security-team/issues/11857). The
decision to call `generic` entity definition comes from the fact that
any entity can be described with the `entity` field - user, host,
service, database, queue, subscription and so on. Therefore it makes
sense to have the concept called `generic` entity, meanwhile the
existent entity definitions will be called concrete entities, because
they describe a very concrete type of entity (currently user, host,
service).
Other changes included on this PR:
- Don't override `entity.name` with `entity.id`, only set if no value is
found
- Migrate the usage of `entity.type` as the entity definition type to
`entity.EngineMetadata.Type`
- Changes touching Entity Analytics code around
`getRiskEngineEntityTypes` and `getAssetCriticalityEntityTypes`. There
was a somewhat unnecessary and duplicated logic in these functions which
essentially described the concrete entity definitions to be used by
entity analytics flows. A new function called
`getEntityAnalyticsEntityTypes` was introduced which unifies this logic
and returns the entity types that Entity Analytics care about.
Video of a scroll through the entities processed by the generic entity
store, source of the data is cloudbeat asset management integration.
https://github.com/user-attachments/assets/450afd05-dee0-4449-aaec-2cd69645d6ec
#### How to test:
- In Advanced Settings (`/app/management/kibana/settings`), enable
`securitySolution:enableAssetInventory`
<img width="883" alt="image"
src="https://github.com/user-attachments/assets/c342abb2-efb3-40a8-b945-d9558f085f34"
/>
- In Entity Store management (`/security/entity_analytics_entity_store`)
enable entity store
<img width="1251" alt="image"
src="https://github.com/user-attachments/assets/41f709e1-0aea-47dc-9c98-ffaebf18fdb1"
/>
- Verify Generic Engine Status
<img width="1203" alt="image"
src="https://github.com/user-attachments/assets/d26b764a-4695-436e-85f7-e3ed7df5a3be"
/>
- Ingest documents with `entity.id` and `entity.*` fields. Personally I
run `cloudbeat` asset discovery locally
- Verify ingested documents in
`.entities.v1.latest.security_generic_default`
<img width="1496" alt="image"
src="https://github.com/user-attachments/assets/88286cb9-38c1-4f9d-83a7-57ba33811c60"
/>
--
**OBS: Also test enabling the store without the uiSetting enabled, so
you can make sure that it doesn't enable**
### 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]
[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
- [x] 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.
- [x] [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.
- [x] I see risk on performance, given the amount of aggregations the
generated transform does
- tested, although we see a higher spike in CPU than before, it's behind
a feature flag and it's going to be used in controlled data sets (entity
centric logs that contain `entity.id` field) we decided it's good enough
to go.
- [ ] Enablement/disablement of entity store in a different uiSetting
configuration.
- [ ] Enable entity store with `securitySolution:enableAssetInventory`
disabled. Then enable `securitySolution:enableAssetInventory` ==> No
generic entity definition installed. You can manually install it in the
EntityStore status page
- [ ] Enable entity store with `securitySolution:enableAssetInventory`
enabled. Then disable `securitySolution:enableAssetInventory` definition
==> hanging assets of generic entity store that can be deleted manually
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/security-team/issues/10837
**WIP Draft**
Add first integration test for Security Solution's Entity Store. This
test checks basic API endpoint (`status`) and tests the first of three
transforms (`host`) on a single field (`host.ip`).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR adds the auto-increase the fields limit on startup when an
alerts index reaches its limits because of the dynamic fields.
# To verify:
To be able to test this PR we need a rule type that adds dynamic fields.
I used the custom threshold rule for this:
Go to the custom threshold rule type definition and change its
alerts.mappings to:
```
mappings: {
// dynamic: true,
fieldMap: {
'kibana.alerting.grouping': {
type: 'object',
dynamic: true,
array: false,
required: false,
},
...legacyExperimentalFieldMap,
...Array(412)
.fill(0)
.reduce((acc, val, i) => {
acc[`${i + 1}`] = { type: 'keyword', array: false, required: false };
return acc;
}, {}),
},
dynamicTemplates: [
{
strings_as_keywords: {
path_match: 'kibana.alert.grouping.*',
match_mapping_type: 'string',
mapping: {
type: 'keyword',
ignore_above: 1024,
},
},
},
],
},
```
Above changes adds 412 dummy fields to the alerts index to make it close to reach its fields limit (default: 2500).
And makes everything under `kibana.alert.grouping` path to be added to the index as dynamic fields.
Then apply the below changes to the custom threshold rule executor:
```
const grouping: Record<string, string> = {};
groups?.forEach((groupObj) => (grouping[groupObj.field] = groupObj.value));
const { uuid, start } = alertsClient.report({
id: `${group}`,
actionGroup: actionGroupId,
payload: {
[ALERT_REASON]: reason,
[ALERT_EVALUATION_VALUES]: evaluationValues,
[ALERT_EVALUATION_THRESHOLD]: threshold,
[ALERT_GROUP]: groups,
// @ts-ignore
['kibana.alerting.grouping']: grouping,
...flattenAdditionalContext(additionalContext),
...getEcsGroups(groups),
},
});
```
Above changes add the selected groups under `kibana.alerting.grouping` path.
Then:
- Run ES with ` path.data=../your-local-data-path` to keep the data for the next start.
- Run Kibana
- Create a custom threshold rule that generates an alert and has at least 2 groups.
- Let the rule run.
- Go to `Stack Management` > `Index Management` and search for observability threshold index.
- Check its mappings, it should show the dummy fields you have added to the rule type and the first grouping you have selected while you were creating the rule type.
- Go to the Dev Tools and find your alert in the `.internal.alerts-observability.threshold.alerts-default-000001` index.
The other groups you have selected should be saved under `_ignored` field:
```
"_ignored": [
"kibana.alerting.grouping.host.name"
],
```
- Stop Kibana
- increase the number of dummy fields you have added to the rule type definition:
```
...Array(412) <-- make this greater than 412
.fill(0)
```
- Start kibana again.
- The new fields should be added to the mappings. Check them on `Stack Management` > `Index Management`
- Check also the index settings: `Stack Management` > `Index Management` > `.internal.alerts-observability.threshold.alerts-default-000001` > settings tab.
- `"mapping" > "total_fields" > "limit" ` should be greater than 2500
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR attempts to simplify our Cypress tests to focus in on what
exactly we want a test to be doing. Many of our rule creation cypress
tests were testing rule creation, rule edit, rule details and more. This
results in a lot of flake and us triaging tests that often test things
other than what we're ultimately trying to answer.
I tried to simplify it so the rule specific tests simply answer - can we
create this rule type in the UI? Then there's a single test for checking
the entire flow of create rule -> rule details and check for alerts. The
FTRs should be ensuring that the rules generate alerts as expected so we
don't need to check this for every rule type in cypress.
I also moved alert suppression into it's own folder as there is a lot of
specific logic to test around that.
## Summary
In QAF David added a possibility to spin up MKI project with custom role
set and ready to use.
Originally FTR was using reserved name `'customRole'` for internal
Kibana role to be mapped with native custom role in the project.
Both Scout and FTR use `kbn/test` to simulate SAML authentication, but
the new framework will allow to run the tests in parallel. That said, we
need to support multiple custom role credentials (one pair per worker)
and for simplicity we decided to use the same keys:
To run your tests locally against MKI you need to add a new Cloud user
entry in `user_roles.json`:
```
"custom_role_worker_1": { "username": ..., "password": ... }, // FTR requires only the first entry
"custom_role_worker_2": { "username": ..., "password": ... },
...
```
The test change is minimal:
<img width="559" alt="image"
src="https://github.com/user-attachments/assets/572103a3-13b2-4e6c-b9d2-5e55b03ac51c"
/>
---------
Co-authored-by: Cesare de Cal <cesare.decal@elastic.co>
Currently streams doesn't allow you to delete an orphaned stream because
`getPipelineTargets` required the data stream to exist.
This PR fixes the problem by handling the case gracefully.
The listing page didn't handle "orphaned" streams properly (classic data
streams which have a configuration on the stream level but the
underlying data stream is not available because it got deleted).
This PR fixes that and adds an integration test for it
<img width="774" alt="Screenshot 2025-04-10 at 16 07 15"
src="https://github.com/user-attachments/assets/da15c56b-7dbd-4070-ab6d-4235132da8ed"
/>
In this picture, `logs-test-default` is orphaned.
To test:
* Create a new classic stream (e.g. via executing
```
POST logs-mylogs-default/_doc
{ "message": "Test" }
```
* Go into the streams UI and add a processor for this stream
* Delete the data stream via stack management or via
```
DELETE _data_stream/logs-mylogs-default
```
* Go to the streams listing page
## Summary
This PR introduces the first building blocks for the [Entity Analytics
Privileged
Monitoring](https://github.com/elastic/security-team/issues/9971).
We follow the approach used in the Entity Store and add a new "Engine",
which consists of the following components:
* Public API
* INIT and HEALTH routes
* Kibana task
* Privilege Monitoring Data Client
* Engine Saved Object
* API key manager
* Related storage indices
* Feature Flag: `privilegeMonitoringEnabled` set to `false` by default.
* API integration test configuration
* only tests that the health endpoint is available
* Auditing and Telemetry
## Testing steps
1. Make sure to add `privilegeMonitoringEnabled` to your
`kibana.dev.yaml`
2. In devtools, ensure the API is working with `GET
kbn:/api/entity_analytics/monitoring/privileges/health`
3. Start the engine with: `POST
kbn:/api/entity_analytics/monitoring/engine/init`
4. Look for `DEBUG` logs mentioning the
`entity_analytics:monitoring:privileges:engine` task
---------
Co-authored-by: CAWilson94 <charlotte.wilson@elastic.co>
Co-authored-by: Charlotte Alexandra Wilson <CAWilson94@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[Preconfigured
connectors](https://www.elastic.co/guide/en/kibana/current/pre-configured-connectors.html)
are those that are specified via the `kibana.yml` config, and thus they
can't be deleted. In tests, we've hardcoded their ids to skip deleting
them when we need to clean up the tests' state.
Sometimes, the id of a preconfigured connector gets changed by somebody,
which breaks tests of multiple teams in MKI pipelines, such as the
periodic pipeline or the release quality gates. The problem is that it
doesn't happen on CI where Kibana doesn't have any preconfigured
connectors, so this feedback loop is too long. When tests in an MKI
pipeline break, it's not immediately clear what happened and who should
fix it. Eventually it gets fixed by someone [like
this](https://github.com/elastic/kibana/pull/217570/files).
Instead of hardcoding the ids, we should dynamically determine if a
connector is preconfigured and if it should be deleted by a test or not.
This is possible to do as each connector has the corresponding
`is_preconfigured` property.
<img width="1073" alt="Screenshot 2025-04-10 at 14 16 15"
src="https://github.com/user-attachments/assets/e330cd5f-c9f0-43da-b4b4-f2a0a2fd10a5"
/>
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
Fixes error message when attempting to preview an index template which
is used by a data stream.
When previewing a saved index template, a index template name and index
pattern were provided. If the index pattern didn't match data streams
that relied on the index template (and they never did) an error would be
shown. As it turns out, supplying the index pattern was entirely
unnecessary. This PR simply removes the index pattern from the api call
and adds a test to make sure that preview functionality works when index
templates match data streams.
Follow up to https://github.com/elastic/kibana/pull/195174
Closes https://github.com/elastic/kibana/issues/212781
**Resolves: https://github.com/elastic/security-docs/issues/3019**
## Summary
In this PR I am improving documentation for the bulk_actions endpoint.
The focus is on improving descriptions of parameters and providing
examples for all important situations, especially setting / adding
actions.
# Testing
1. cd x-pack/solutions/security/plugins/security_solution
2. yarn openapi:bundle:detections
3. Take the bundled file
(docs/openapi/ess/security_solution_detections_api_2023_10_31.bundled.schema.yaml)
and load it into bump.sh console to see the changes.
4. Compare the changes with the [Legacy
documentation](https://www.elastic.co/guide/en/security/current/rule-api-overview.html)
You can also use this [link](https://bump.sh/jkelas/doc/kibana_wip/)
where I deployed the generated bundled doc.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Part of Epic: https://github.com/elastic/kibana-team/issues/1439
Requires: https://github.com/elastic/kibana/issues/212903
Changes:
1. Moves the Solution Side Nav away from the "four squares" design
pattern: where clicking the item label opens a landing page and the item
icon opens the secondary nav panel. This was a custom component
implemented in the Kibana package, not part of the EUI
`EuiCollapsibleNavBeta` component.
2. Changes some usage of `@emotion/css` to `@emotion/react` for better
developer experience
### Screenshots
<details><summary>Before</summary>
</details>
<details><summary>After</summary>
</details>
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### 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.
- [ ] This design pattern was only used in Security Solution. There is a
small risk of regression issues in Security Solution navigation. This
was mitigated by manual testing during development.
## Summary
Closes [#209791](https://github.com/elastic/kibana/issues/209791)
Closes [#204378](https://github.com/elastic/kibana/issues/204378)
### Improve Knowledge Base Installation and Inference Endpoint
Management
#### Enhancements
- The **"Install Knowledge Base"** button is only shown when there is no
inference endpoint. If the inference endpoint creation fails, an error
notification is displayed.
- When an inference endpoint **exists and is ready**, no buttons or
messages are shown.
- If the installation was in progress and **succeeded**, a success
message is displayed.
- If an inference endpoint is present, users can **inspect the state of
the model deployment** to diagnose issues.
- When an inference endpoint exists but has an **error**, users can
retry the installation.
#### Inspection & Troubleshooting
Users can inspect the inference endpoint's deployment status, including:
- **Model is deploying**
- **No ML node available**
- **Insufficient memory available**
https://github.com/user-attachments/assets/03a91120-173c-4dc9-b6f2-59a8c8c8defb
### Suggested Improvements
- Display **autoscaling information** for better resource insights.
- Show **ML node details** to help users understand the infrastructure.
- Allow users to **install, deploy, and stop the model** directly from
the inspection popup.
These changes enhance visibility, troubleshooting, and control over
inference endpoint deployment. 🚀
### 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
This PR adds the structure for workchat FTR tests and adds a few initial
tests as an example.
### Details about initially added tests
New test directories:
- `x-pack/test_serverless/api_integration/test_suites/chat`
- load a few common tests (that run on all project types)
- run `platform` security tests (taken over from `search` project type)
- `x-pack/test_serverless/functional/services/svl_chat_navigation.ts`
- load the `home page` common test
- run a simple navigation test, using the `svlChatNavigation` service
that has been introduced as an example
Note that these tests mostly serve as examples to prove things are
actually running and will have to be adjusted / removed / extended over
time. The purpose of this PR is NOT to add proper test coverage.
Closes#213469
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Fixes [#215706](https://github.com/elastic/kibana/issues/215706)
## Summary
This fixes the problem where Otel span links were not considered a
collection of links.
<img width="1721" alt="image"
src="https://github.com/user-attachments/assets/bce354d5-8473-41db-856e-3bbb66b88c18"
/>
### How to test
Run: `node scripts/synthtrace span_links.ts --live --uniqueIds --clean
--logLevel=debug --scenarioOpts pipeline=apmToOtel` and wait a few
minutes
Navigate to Services Inventory -> product consumer -> Transactions and
inspect the span links from `Span B`
Run the query below to confirm that there are `links` with a collection
of items
```
GET traces-*otel*/_search
{
"query": {
"exists": {
"field": "links*"
}
}
}
```
## Summary
Splitting long running config:
`x-pack/test/functional/apps/saved_query_management/config.ts` **~57
min** into
- x-pack/test/functional/apps/saved_query_management/config.ts 35m
- x-pack/test/functional/apps/saved_query_management/config.v2.ts 25m
17s
ideally we need to split both even more, but I will leave it for the
later (probably Data-Discovery Team have some ideas how to re-org it?)
Closes https://github.com/elastic/kibana/issues/209386
## Summary
1. The option to archive conversations are enabled via the conversation
contextual menu.
2. Archived conversations can be viewed under the "Archived" section of
the conversation list.
3. Only the owner of the conversation can archive and unarchive.
4. Once archived, the conversation cannot be continued until unarchived.
5. If the archived conversation is shared, other users (who are not the
owner) can duplicate the conversation, if they wish to continue the
conversation.
6. The archived section of the conversation list is collapsed by
default.
7. Updating the conversation such as title updates, regenerating,
providing chat feedback are disabled for archived conversations
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] [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>
