## Summary
Closes https://github.com/elastic/kibana/issues/205558
Updates the RRule library to correctly handle some scenarios with
invalid parameters that would either cause it to return strange
recurrence data or to infinitely loop. Specifically:
- On `RRule` object creation, removes and ignores any `bymonth`,
`bymonthday`, `byweekday`, or `byyearday` value that's out of bounds,
e.g. less than 0 or greater than the number of possible months, days,
weekdays, etc.
- Successfully ignores cases of `BYMONTH=2, BYMONTHDAY=30` (February
30th), an input that's complicated to invalidate but still won't ever
occur
Allowing these values to go unhandled led to unpredictable behavior. The
RRule library uses Moment.js to compare dates, but Moment.js months,
days, and other values generally start at `0` while RRule values start
at `1`. That led to several circumstances where we passed Moment.js a
value of `-1`, which Moment.js interpreted as moving to the
***previous*** year, month, or other period of time.
At worst, this could cause an infinite loop because the RRule library
was constantly iterating through the wrong year, never reaching the date
it was supposed to end on.
In addition to making the RRule library more able to handle these cases,
this PR also gives it a hard 100,000 iteration limit to prevent any
possible infinite loops we've missed.
Lastly, the Snooze Schedule APIs also come with additional validation to
hopefully prevent out of bounds dates from ever being set.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
Co-authored-by: Janki Salvi <jankigaurav.salvi@elastic.co>
Co-authored-by: adcoelho <antonio.coelho@elastic.co>
## Summary
Addresses the following:
* Simplify `isInTargetFolder`, and leverage existing
`calculateModuleTargetFolder`. It solves a bug with "current" location
being incorrectly determined, as we were using the `group` and
`visibility` inferred from path, rather than those in the manifest.
* Move the `pre-relocation` hook to BEFORE calculating the list of
modules. This allows to update a manifest to re-relocate a module (e.g.
when changing its group or visibility).
* Fix a bug that caused modules under `src/core/packages` to not be
considered in the "correct location".
* Fix a bug in the replace logic specific to `pipeline.ts`. We were
updating paths that we shouldn't have updated.
## Summary
- [x] Updates the AVC banner title and blog link
- [x] Banner will remain visible until EOY 2025
- [x] Confirm that the original AVC banner code (not the part that hides
it EOY of 2024) is present in 8.16, 8.17 and 8.x branches
# Screenshots
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR:
- Updates the Kibana [Alert and action
settings](https://www.elastic.co/guide/en/kibana/current/alert-action-settings-kb.html)
page to be based off of a YAML source file
(`/docs/settings-gen/source/kibana-alert-action-settings.yml`) that is
manually converted to Asciidoc format
(`kibana-alert-action-settings.asciidoc`) by means of a Perl script
(`docs/settings-gen/parse-settings.pl`). A preview of the new, generated
page is
[here](https://kibana_bk_191787.docs-preview.app.elstc.co/guide/en/kibana/master/alert-action-settings-kb.html).
- Adds the `docs/settings-gen/parse-settings.pl` script which does the
YAML → Asciidoc conversion.
All new files are added to the `/docs/source-gen` folder.
This is a trial run updating only one page of settings in the docs.
Later, in separate PRs, we plan to convert other pages. After all Kibana
settings pages have been converted, we would ask that the Perl script be
run automatically as part of the CI whenever the YAML files in
`/docs/source-gen` are added or updated.
**Notes:**
- The Docs team is happy to own and maintain the Perl script (sorry to
use Perl - it's the only scripting language that I know).
- In time we also plan to convert all of these files from Asciidoc to
Markdown.
- When we eventually/hopefully get the rest of the Kibana settings files
converted, we will announce the settings doc process to the Kibana team
by email and/or in the Kibana newsletter.
Big thanks to the amazing @lukeelmers and @KOTungseth for guiding this!
---
Why are we doing this? We aim to:
- Create a more consistent appearance for settings across all of the
docs.
- Make it easier for people to contribute, since all Asciidoc/Markdown
formatting is handled by a script.
- Make it more apparent which settings may be missing info, such as the
default values, available options, etc.
---
P.S. I haven't worked in the Kibana repo very much and would appreciate
any help navigating the CI checks.
Rel: https://github.com/elastic/docs-projects/issues/239
Clean up embeddable folder structure.
PR also splits `COMMON_EMBEDDABLE_GROUPING` into
`ADD_PANEL_ANNOTATION_GROUP`, `ADD_PANEL_LEGACY_GROUP`, and
`ADD_PANEL_OTHER_GROUP` to provide a more contextually relevant name.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
So that it can be used from `streams_app` (o11y).
See https://github.com/elastic/kibana/pull/204309
Steps to relocate:
1. Fetch latest `main`
2. Update the `group` and/or `visibility` in the module's manifest.
3. Run `node scripts/relocate --moveOnly
@kbn/saved-objects-tagging-plugin`
## Summary
This PR replaces the `useIsDarkTheme()` hook with EUI's `colorMode`.
Since this was the last hook in `@kbn/ml-kibana-theme` left this removes
the whole package too.
Note that the hook subscribed to an observable and was able to update
the theme in place. EUI's `colorMode` will only be updated after a page
refresh. Since updating the Kibana advanced setting to enable dark mode
requires a full page refresh too, I guess it's fair to remove this
behavior in favor of this simplification.
In the long run we should aim for getting rid of these checks altogether
and rely on dark-mode-aware EUI tokens.
### 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
- [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.
## Summary
Setting a desired window length (15 seconds) for the background task
utilization window running average and calcuating the number of entries
to average based on the poll interval. Updating config to be optional so
this value can still be configured but if not configured will be
calculated.
## To Verify
- Add a console log to log the window size
```
--- a/x-pack/platform/plugins/shared/task_manager/server/monitoring/background_task_utilization_statistics.ts
+++ b/x-pack/platform/plugins/shared/task_manager/server/monitoring/background_task_utilization_statistics.ts
@@ -59,6 +59,7 @@ export function createBackgroundTaskUtilizationAggregator(
workerUtilizationRunningAverageWindowSize ??
WORKER_UTILIZATION_RUNNING_AVERAGE_WINDOW_SIZE_MS / pollInterval;
+ console.log(`workerUtilizationWindowSize ${workerUtilizationWindowSize}`);
const taskRunEventToAdhocStat = createTaskRunEventToAdhocStat();
const taskRunAdhocEvents$: Observable<Pick<BackgroundTaskUtilizationStat, 'adhoc'>> =
```
- Start Kibana with `mget` claim strategy. The window size should be 30
- Start Kibana with `update_by_query` claim strategy. The window size
should be 5
- Set `xpack.task_manager.worker_utilization_running_average_window: 22`
in your Kibana config and start Kibana. The window size should be 22
(takes the configured window size if it's passed in).
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Stricter defaults for plugin types: `Plugin` and `CoreSetup` now have
empty objects as defaults instead of `object` which is assignable to
anything basically. This catches some type errors, but my motivation for
this is to allow something like:
```ts
function createPlugin ():Plugin<MySetupContract, MyStartContract, MySetupDependencies, MyStartDependencies> {
return {
// look ma, no additional typing necessary
setup ( coreSetup, pluginsSetup ) {
},
start ( coreStart, pluginsStart ) {
}
}
}
```
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 13 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/core-chrome-browser-internal` |
`src/core/packages/chrome/browser-internal` |
| `@kbn/core-custom-branding-browser` |
`src/core/packages/custom-branding/browser` |
| `@kbn/core-custom-branding-browser-internal` |
`src/core/packages/custom-branding/browser-internal` |
| `@kbn/core-custom-branding-browser-mocks` |
`src/core/packages/custom-branding/browser-mocks` |
| `@kbn/core-custom-branding-common` |
`src/core/packages/custom-branding/common` |
| `@kbn/core-custom-branding-server` |
`src/core/packages/custom-branding/server` |
| `@kbn/core-custom-branding-server-internal` |
`src/core/packages/custom-branding/server-internal` |
| `@kbn/core-custom-branding-server-mocks` |
`src/core/packages/custom-branding/server-mocks` |
| `@kbn/core-ui-settings-browser` |
`src/core/packages/ui-settings/browser` |
| `@kbn/core-ui-settings-browser-internal` |
`src/core/packages/ui-settings/browser-internal` |
| `@kbn/core-ui-settings-common` |
`src/core/packages/ui-settings/common` |
| `@kbn/core-ui-settings-server` |
`src/core/packages/ui-settings/server` |
| `@kbn/core-ui-settings-server-internal` |
`src/core/packages/ui-settings/server-internal` |
<details >
<summary>Updated references</summary>
```
./docs/developer/architecture/core/patterns-scoped-services.asciidoc
./docs/developer/architecture/core/uisettings-service.asciidoc
./package.json
./packages/core/custom-branding/core-custom-branding-common/index.ts
./packages/kbn-ts-projects/config-paths.json
./src/core/packages/chrome/browser-internal/jest.config.js
./src/core/packages/custom-branding/browser-internal/jest.config.js
./src/core/packages/custom-branding/browser-mocks/jest.config.js
./src/core/packages/custom-branding/server-internal/jest.config.js
./src/core/packages/custom-branding/server-mocks/jest.config.js
./src/core/packages/ui-settings/browser-internal/jest.config.js
./src/core/packages/ui-settings/browser/jest.config.js
./src/core/packages/ui-settings/common/jest.config.js
./src/core/packages/ui-settings/server-internal/jest.config.js
./src/core/packages/ui-settings/server/jest.config.js
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/platform/plugins/private/transform/public/app/common/time_zone_utils.ts
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/core/packages/chrome/browser-internal/jest.config.js:12
src/core/packages/chrome/browser-internal/tsconfig.json:2
src/core/packages/custom-branding/browser-internal/jest.config.js:12
src/core/packages/custom-branding/browser-internal/tsconfig.json:2
src/core/packages/custom-branding/browser-mocks/jest.config.js:12
src/core/packages/custom-branding/browser-mocks/tsconfig.json:2
src/core/packages/custom-branding/browser/tsconfig.json:2
src/core/packages/custom-branding/common/tsconfig.json:2
src/core/packages/custom-branding/server-internal/jest.config.js:12
src/core/packages/custom-branding/server-internal/tsconfig.json:2
src/core/packages/custom-branding/server-mocks/jest.config.js:12
src/core/packages/custom-branding/server-mocks/tsconfig.json:2
src/core/packages/custom-branding/server/tsconfig.json:2
src/core/packages/ui-settings/browser-internal/jest.config.js:12
src/core/packages/ui-settings/browser-internal/tsconfig.json:2
src/core/packages/ui-settings/browser/jest.config.js:12
src/core/packages/ui-settings/browser/tsconfig.json:2
src/core/packages/ui-settings/common/jest.config.js:12
src/core/packages/ui-settings/common/tsconfig.json:2
src/core/packages/ui-settings/server-internal/jest.config.js:12
src/core/packages/ui-settings/server-internal/tsconfig.json:2
src/core/packages/ui-settings/server/jest.config.js:12
src/core/packages/ui-settings/server/tsconfig.json:2
```
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/205411
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come soon. These first PRs
are simply preparing the code by wiring up the `UserProvideService`.
### 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)
### 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.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
Closes#203740
## Summary
This PR fixes failing test by changing read role permission to include
`streams` and `apm`. As I mentioned in this
[comment](https://github.com/elastic/kibana/issues/203740#issuecomment-2574907832)
I saw some 403 errors related to some `streams` and `apm` APIs requests
so this should fix the test as it was meant to test if the dashboards
tab behaves correctly based on the admin/read-only role.
However, we should think about a solution to those errors in case we
have this scenario (read-only user role without apm/streams access) and
have a better error message/explanation of what is missing instead of
only showing the error toasts - I saw that we reverted
(https://github.com/elastic/kibana/pull/202418) already a solution
(https://github.com/elastic/kibana/issues/200151) for APM because of
other issues but now that we also include the `streams`
(https://github.com/elastic/kibana/pull/200060) (not sure if we need to
do the request in infra but that's probably a different discussion) it's
something we can revisit at one point to improve the user experience.
## Summary
`build_snapshot` was using wrong Gradle task when building ES from
source for Apple silicon laptops
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[@types/fnv-plus](https://togithub.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/fnv-plus)
([source](https://togithub.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/fnv-plus))
| devDependencies | patch | [`^1.3.0` ->
`^1.3.2`](https://renovatebot.com/diffs/npm/@types%2ffnv-plus/1.3.0/1.3.2)
|
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Sergi Romeu <sergi.romeu@elastic.co>
## Summary
This PR removes usages of `@testing-library/react-hooks` from the
codebase, as we've transitioned to using `@testing-library/react`
especially that it provides the same utils we need and the later package
is not supported for react 18. alongside this ~other instance of the
usages for `@testing-library/react-hooks` have been removed~ an eslint
rule has been enabled to prevent further usages of the mentioned
package.
<!--
### 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/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Adds necessary permissions to write to the `agentless-*` index. See:
- Elasticsearch PR: https://github.com/elastic/elasticsearch/pull/118644
- Context: https://github.com/elastic/security-team/issues/11104
As part of https://github.com/elastic/security-team/issues/11104, we
need to write integration data that needs to be persistent. The
implementation we are working on, uses Elasticsearch as the storage
mechanism for this data.
Normally, integrations write to data streams instead of normal ES
indices. However, data streams cannot provide a generic implementation
for our use case and thus we need a normal ES index.
This PR grants permissions from the fleet service account to the
agentless integrations to write to `agentless-*` ES indices.
In
`x-pack/plugins/fleet/server/services/agent_policies/package_policies_to_agent_permissions.ts`
there are other examples of other integrations that need ES index
permissions so there is prior art in doing this. The difference with
this PR however, is that we need to conditionally merge the extra
`agentless-*` permissions with any potential existing data stream
permissions since we are dealing with arbitrary agentless integrations.
Adds support for image content parts in the Inference plugin. Only
base64 encoded images are supported, as this capability is shared across
all three LLM providers.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This change sets a relative date range to the host details link from the
auto-detect onboarding flow. This prevents a situation when host details
page would open saying there is no data and it would be stuck on a fixed
date range unable to load data even if user refreshes the page.
Somehow, even when onboarding flow can detect that the data was already
ingested, the host details page might not see it for some reason. This
requires a further investigation, but relative data range is a fix for
the time being.
When manually syncing ML saved objects using the sync flyout, the saved
objects are now tagged to the `*` space. This now matches the behaviour
of the server side auto sync and the sync which happens when the trained
models page is loaded.
The trained models page load sync has been extended to the AD and DA
jobs lists and the overview page.
If the user does not have write permission for ML in every space they
cannot sync jobs to the `*` space.
In this situation a warning is shown in the flyout and when they sync,
the jobs/models will only be added to the current space.
## Summary
Fixes https://github.com/elastic/kibana/issues/201267
Before migrating the API tests to be deployment-agnostic, we had already
seen some flaky results for this test
(https://github.com/elastic/kibana/issues/197912). After completing the
migration, the error occurred again.
This PR aims to fix the potential issue by ensuring that all existing
alerts are cleared before creating the alerts used in the test case.
Co-authored-by: jennypavlova <dzheni.pavlova@elastic.co>
Closes#196096
## Summary
Wrong successful message with error notification pop up on adding a
wrong format file under bulk import for knowledge base
[#196096](https://github.com/elastic/kibana/issues/196096)
---------
Co-authored-by: Søren Louv-Jansen <sorenlouv@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Partially addresses:** https://github.com/elastic/kibana/issues/171520
## Summary
This PR adds is built on top of https://github.com/elastic/kibana/pull/193828 and https://github.com/elastic/kibana/pull/196948 and adds the following editable components for Threat Match rule type
- threat_index
- threat_query
- threat_mapping
- threat_indicator_path
- ~~threat_language~~ `threat_language` was merged with `threat_query`
## Details
This PR make a set of changes to make existing Threat Match form fields easily reusable as editable components and type safe when used in forms. In particular the following was done
- Fixes a bug blocking Threat Match rules upgrading
- Existing functionality was refactored to have reusable self-contained editable components for `threat_index`, `threat_query`, `threat_mapping` and `threat_indicator_path` rule fields
- `threat_language` was removed since query type is included in `threat_query` field and can be edited with Query Bar
- threat mapping input was split into separate component for individual fields to be reused
- `ThreatMatchComponent` was refactored to be a controlled component instead of uncontrolled
`ThreatMatchComponent` has a feature preventing users removing the single last entry. Instead deleting the last entry the delete button clears inputs. That functionality didn't work properly in Prebuilt Rule Customization workflow and rule creation/editing forms after creating a reusable `ThreatMappingEdit` component. Instead of trying to find a tricky fix `ThreatMatchComponent` was refactored to remove internal state. The feature preventing users removing the single last entry was reimplemented in `ThreatMappingEdit` component.
- Fixes a bug reproducible in `main` where validation errors duplicated described in a [comment](https://github.com/elastic/kibana/pull/200308#discussion_r1869385209)
- Fixes a bug reproducible in `main` allowing to save unknown source indices or indicator indices fields described in a [comment](https://github.com/elastic/kibana/pull/200308#discussion_r1869412952)
## How to test
- Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled
- Allow internal APIs via adding `server.restrictInternalApis: false` to `kibana.dev.yaml`
- Clear Elasticsearch data
- Run Elasticsearch and Kibana locally (do not open Kibana in a web browser)
- Install an outdated version of the `security_detection_engine` Fleet package
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"force":true}' http://localhost:5601/kbn/api/fleet/epm/packages/security_detection_engine/8.14.1
```
- Install prebuilt rules
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 1" -d '{"mode":"ALL_RULES"}' http://localhost:5601/kbn/internal/detection_engine/prebuilt_rules/installation/_perform
```
- Open a `threat_match` rule for editing. For example `Threat Intel Hash Indicator Match` with rule_id `aab184d3-72b3-4639-b242-6597c99d8bca`.
- Edit `Indicator index patterns`, `Indicator index query` and/or `Indicator filters`, `Indicator mapping` and `Indicator prefix override` fields
- Open `Detection Rules (SIEM)` Page -> `Rule Updates` -> click on `Threat Intel Hash Indicator Match` rule -> expand each Threat Match rule type specific field -> press `Edit` button
## Screenshots
Threat Match Query edit component
<img width="1720" alt="image" src="https://github.com/user-attachments/assets/c7183ddf-8795-424c-90e4-b7eff14d9f69">
Threat Match Index edit component
<img width="1727" alt="image" src="https://github.com/user-attachments/assets/5e50cc98-6cc6-464d-a29d-89d31718482d">
Threat Match Mapping edit component
<img width="1725" alt="image" src="https://github.com/user-attachments/assets/aba6a723-0283-4b9e-80d2-376b1dea102e">
Threat Match Indicator Path edit component
<img width="1725" alt="image" src="https://github.com/user-attachments/assets/59aa12d9-377c-4c24-ab40-fef19e55e44e">
Threat Match Mapping unknown field names validation warnings
<img width="979" alt="Screenshot 2024-12-18 at 12 45 41" src="https://github.com/user-attachments/assets/0cfd8ae3-4865-49f8-a4ac-bafe19e01671" />
<img width="1094" alt="Screenshot 2024-12-18 at 12 45 53" src="https://github.com/user-attachments/assets/7f204e12-fe65-4a64-a029-1bb44ea366a3" />
<img width="2552" alt="Screenshot 2024-12-18 at 12 47 05" src="https://github.com/user-attachments/assets/53ac4612-f443-4d89-9474-8693ab9ced2d" />
<img width="2550" alt="Screenshot 2024-12-18 at 12 47 15" src="https://github.com/user-attachments/assets/1e345c88-9427-44ba-bc25-0164c39d1700" />
## Summary
Handles :
### Issue with Batches
- https://github.com/elastic/kibana/issues/201405
- Timeline had a bug where if users fetched multiple batches and then if
user adds a new column, the value of this new columns will only be
fetched for the latest batch and not old batches.
- This PR fixes that ✅ by cumulatively fetching the data for old batches
till current batch `iff a new column has been added`.
- For example, if user has already fetched the 3rd batch, data for
1st,2nd and 3rd will be fetched together when a column has been added,
otherwise, data will be fetched incrementally.
### Issue with Elastic search limit
- Elastic search has a limit of 10K hits at max but we throw error at
10K which should be allowed.
- Error should be thrown at anything `>10K`. 10001 for example.
- ✅ This PR fixes that just for timeline by allowing 10K hits.
### Removal of obsolete code
Below files related to old Timeline code are removed as well:
-
x-pack/plugins/security_solution/public/timelines/components/timeline/footer/index.test.tsx
-
x-pack/plugins/security_solution/public/timelines/components/timeline/footer/index.tsx
---------
Co-authored-by: Philippe Oberti <philippe.oberti@elastic.co>
1. Migrated stack-connector `.inference` to use share UI components
https://github.com/elastic/kibana/pull/203204
2. Extended package `@kbn/inference-endpoint-ui-common` to support edit
mode for the form of the connector, by adding the optional property
`isEdit` to `InferenceServiceFormFields` component
3. Resolves flaky timing out test
https://github.com/elastic/kibana/issues/205129
---------
Co-authored-by: Samiul Monir <samiul.monir@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
