## Summary
This pr fixes a bug with the RouteCapture component, used at a high
level in the security solution component tree, to reflect url changes
into redux. The code previously used the full result of
'react-router-dom' 's useLocation hook as the payload, which contains 4
parameters, pathname, search, hash that we make use of, and a 4th that
was added sometime later by the library that is essentially a random id
generated every time the hook is called, called key. We have never used
this, and it was being inadvertently copied into the redux state, and
also causing some other actions or hooks based listeners to run I think
as well.
Below is the contrived example of going from the home page to an empty
alerts page, and you can see 4 actions in the after, and 5 in the
before, with 1 updating only the key. May reduce more unneeded actions
with more going on in the page, but exactly how many is not known.
Before:
After:
### Checklist
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
New event created for the video selectors inside rules, dashboards and
alerts cards.
```
export interface OnboardingHubSelectorCardClickedParams {
originStepId: string;
selectorId: string;
}
```
To verify:
Add these lines to kibana.dev.yml
```
logging.browser.root.level: debug
telemetry.optIn: true
```
1. In the onboarding hub, expand the rules card
2. It should log `Report event "Onboarding Hub Step Selector Clicked"`.
https://github.com/user-attachments/assets/c1b1084e-4917-4412-93ed-984a74b6b6b4
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: #215112
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Added `aria-labelledby={flyoutTitleId}` for mentioned places
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>
## Summary
This PR adds support for disabling experimental features using the
existing `xpack.securitySolution.enableExperimental` configuration.
This solves the problem of not being able to disable a feature by config
once the feature has been enabled by default.
### The Challenge
When we start developing a feature under an experimental flag we always
follow the same steps:
1 - Create the experimental flag disabled by default + enable it via
config for testing
2 - Implement the feature
3 - Enable the experimental flag by default when we want to release the
feature.
4 - Deployments can disable the feature via config (as a safety
measure).
5 - Remove the experimental flag after some time.
We start by creating the flag disabled by default while we implement it.
In `experimental_features.ts`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeatureEnabled: false,
[...]
```
And enable it via config with:
```yml
xpack.securitySolution.enableExperimental:
- myFeatureEnabled
```
Once the implementation is done and the experimental flag can be enabled
by default, we have to do a trick:
Since the `xpack.securitySolution.enableExperimental` config can only
turn flags to _true_, instead of setting `myFeatureEnabled: true`, what
we have to do is rename the flag to `myFeatureDisabled` and keep the
value as _false_:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeatureDisabled: false,
[...]
```
Then we also need to do a code refactor to update all the places in the
code where the flag was checked: `if (myFeatureEnabled)` -> `if
(!myFeatureDisabled)`
This way, we have the option of disabling the feature via config (in
case something goes wrong):
```yml
xpack.securitySolution.enableExperimental:
- myFeatureDisabled
```
### A solution
This PR introduces the possibility to turn a flag to _false_ using the
same `xpack.securitySolution.enableExperimental` config. This was
preferable to introducing a new config since this one is already
whitelisted in Cloud UI, can be easily overritten in deployments, and
also because people are used to it.
With these changes, the first two steps would be the same, with the
difference that we won't need to have the _Enabled_ or _Disabled_ word
at the end of the flag name. It could be just the feature name, in
`experimental_features.ts`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeature: false,
[...]
```
And when we need to enable the feature by default, we can just turn it
to `true`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeature: true,
[...]
```
No tedious refactor or confusing naming would be required.
Then, in case we need to disable the feature in a production deployment
for some reason, we could just do this via config :
```yml
xpack.securitySolution.enableExperimental:
- disable:myFeature
```
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes: #214760
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Set correct value for` aria-labelledby` attr.
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>
Closes: #214335
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Added `aria-labelledby={flyoutTitleId}` for mentioned places
## Summary
This PR fixes the issue with the error summary missing items using edot.
It includes e2e tests with synthtrace for both edot and otel services.
TODO
- [x] Test with serverless (waiting for the PR to be deployed)
Tested on serverless works as expected:
<img width="2560" alt="image"
src="https://github.com/user-attachments/assets/8dd7962e-7d66-482d-97fb-0b08882bd04f"
/>
Allow group by for ip fields !!
---------
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/217923
Investigations in https://github.com/elastic/kibana/issues/217368 showed
that there was basically no performance impact to passing the AST across
a thread boundary. But we also didn't detect a pressing reason to remove
the worker.
Since then, however, we noticed another cost associated with the worker:
it's a hefty Javascript file, even in production builds. In addition, we
are doing parsing on the main thread _and_ the worker, so the
`kbn-esql-ast` package is actually being loaded and parsed twice by the
browser, once for the main thread and once for the worker.
This PR removes our worker. Our parsing associated with validation and
autocomplete will still be done asynchronously, but on the main thread.
I do not see any regression in perceived performance.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
This PR closes#215668.
The global parameters are synched in the endpoints where they are
created, edited or deleted.
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Closes: #216147
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Added` aria-labelledby={flyoutTitleId} `for mentioned places
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12007))
These changes add the attack discovery schedules management table.
https://github.com/user-attachments/assets/619ad1d6-d919-4a8d-b743-6a73fbfbf318
## Key changes
* UI side API handlers
* Create schedule workflow
* Schedules table
* Enable schedule from the table
* Disable schedule from the table
* Delete schedule from the table
* Pagination and sorting in find schedules API
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
This PR passes the current sample documents to the default form state
generation for new processors to pick a good default field.
The logic that's actually employed for `dissect` and `grok` is the
following:
* Go through all docs and order string fields occurring by how many
values they have
* Pick the top one from a list of "well known" fields that probably make
sense (in case of a tie, go by a the ordering of the well known fields)
* If no field is found this way, just leave it empty - this still shows
the full table and the user can pick the field they care about
Especially for otel this should be helpful.
## Summary
This PR better separates the request building logic in the detection
engine from query building logic, removes outdated error checking logic,
updates the `singleSearchAfter` `search` call to no longer use the
legacy `meta: true` param, and improves search response type inference.
Closes: https://github.com/elastic/kibana/issues/217511
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Set correct value for `aria-labelledby` attr.
## Summary
When the datatable comes with empty results the visualization fails with
bad way
<img width="396" alt="image"
src="https://github.com/user-attachments/assets/b4e266d7-edbd-452b-9192-84c957fe98db"
/>
With the fix
<img width="756" alt="image"
src="https://github.com/user-attachments/assets/d061d29e-9246-432a-944b-308b88d161e7"
/>
How to replicate:
- Create a field ES|QL control with 2 values (extension and geo.dest).
You can do it with multiple ways. I created with typing `FROM
kibana_sample_data_logs | STATS count = COUNT(*) BY` and then `Create
control`.
- Use the variable in another panel with query: `FROM
kibana_sample_data_logs | WHERE ??field == "css" | KEEP extension` (The
control value should be in the extension). This will work
- Select the second field (geo.dest). This will return an empty query
and will break the table viz.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
This PR makes sure a buggy `security_detection_engine` package doesn't affect a preview installation endpoint. Older security detection rules package versions contain saved object rule duplicates affecting the endpoint.
Having `security_detection_engine` v`8.17.1` package installed `/internal/detection_engine/prebuilt_rules/status` and `/internal/detection_engine/prebuilt_rules/installation/_review` endpoints return a different number of rules available to install.
## Details
Older `security_detection_engine` package versions contain rule saved objects duplicates representing the latest version. For example, `8.17.1` version has a rule `Microsoft 365 User Restricted from Sending Email` with `rule_id` = `0136b315-b566-482f-866c-1d8e2477ba16` and the latest version `206`. Since a package may contain multiple historical rule versions it sticks to the following format `<rule_id>_<version>` where `<rule_id>` is the unique rule's UUID and `<version>` it's version. Some older package versions omit `<version>` for the latest rule version. `Microsoft 365 User Restricted from Sending Email` rule mentioned above has two equal assets corresponding to the latest version with the only difference in the saved object id `0136b315-b566-482f-866c-1d8e2477ba16` and `0136b315-b566-482f-866c-1d8e2477ba16_206`.
Prebuilt rules preview endpoint was designed to handle `<rule_id>_<version>` format only. Consequently, it improperly handles older prebuilt rules package version.
This bug manifested in https://github.com/elastic/kibana/pull/217544 where `security_detection_engine` version has been bumped to `8.18.1`. It resulted in a failed integration test. Further investigation has shown that the test installs an older package version `8.17.1` to assert prebuilt rules upgrade workflow works correctly.
The fix is implemented in `PrebuiltRuleAssetsClient.fetchAssetsByVersion()` by using `Map` to deduplicate prebuilt rule assets.
## 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"
/>
fixes [#189213](https://github.com/elastic/kibana/issues/189213)
## Summary
Checks whether the user has permission to ML before triggering requests
to fetch ML data
### How to test
- Create a user whose role doesn't have permission to ML, but has
permission to O11y apps
- Run `node scripts/synthtrace infra_hosts_with_apm_hosts --live
--clean`
- Navigate to Inventory Infrastructure / Hosts View
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## 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>
Closes https://github.com/elastic/kibana/issues/217994
## Summary
The comment section containing a table that requires horizontal
scrolling was being visually pushed to the right due to the presence of
the user avatar. To ensure the comment section aligns properly with the
rest of the content and doesn't overlap the sidebar reserved for
connectors and custom fields, the `max-width` property was adjusted
accordingly.
The offset comes from:
- the width of the euiAvatar--m (which uses the `xl` size token)
- the left padding of the `euiTimelineItemEvent`, which corresponds to
`euiTheme.size.base` (16px)
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>
