This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `d04ee51` ->
`8df3ca6` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
BUG: https://github.com/elastic/kibana/issues/208907
This PR fixes the issue where user cannot select a different connector
type after mistakenly selecting a wrong one.
### Steps to reproduce without required endpoint installation:
1. Make sure there are no connectors
2. Open "AI Assistant" on one of the security solution pages
3. Press "(+) Add connector" button
4. Connector type selection modal is visible
5. Select "Amazon Bedrock" type (or any other connector type)
6. Cancel the modal
7. Press "(+) Add connector" button again
**ISSUE**: previously selected connector type is being displayed and
there is no way to switch between types
**EXPECTED**: we should show connector type selection modal once
previous one was closed
### Issue recording
https://github.com/user-attachments/assets/48052bf1-4e00-43b7-a63e-f8a7969b9dbf
### Fixed state recording
https://github.com/user-attachments/assets/48be1cc4-0326-43a1-bd57-bb82fc1f19eb
## Details
⚠️ This PR was created by an automated tool. Please review the changes
carefully. ⚠️
Add a workflow that will comment on PRs with AsciiDoc changes.
## Why
During the migration to Elastic Docs v3, the Docs team will focus
exclusively on migrating content.
To maintain consistency, prevent conflicts, and ensure a smoother
transition we will freeze all AsciiDoc changes.
This means you will get a warning when you create AsciiDoc changes in
your PRs.
See https://github.com/elastic/docs-builder/issues/281 for details
If there are any questions, please reach out to the
@elastic/docs-engineering
---------
Co-authored-by: Brandon Morelli <brandon.morelli@elastic.co>
## Summary
We anticipate generating a single document per API version for the
foreseeable future. This PR updates our OAS document merging logic to
avoid adding the `Elastic-Api-Version` header to our spec.
This will also remove this header from current documentation.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Pre-GA, we previously modified the critical path, weekly Quality Gate
pipelines over to non-preemptible images in order to avoid the
inconsistent "agent lost" Buildkite issue that might cause unnecessary
churn.
Now that we're GA, the periodic pipelines are becoming more critical
path as well, and in addition, we're seeing a concerning increase in the
number of "agent lost" issues we're encountering, as described here:
https://github.com/elastic/security-team/issues/11700
As such, this PR is hoping to address this issue for the periodic
pipelines as well.
An invariant we have to handle somehow is if a user made additions to an
unwired data stream via the streams interface, then the underlying data
stream gets deleted.
This is "allowed", since the data stream is not managed by streams.
Currently, the UI breaks if this happens and shows error toasts when
trying to load the doc count or when trying to change processing.
This PR makes this a regular case the API can handle:
* The `GET /api/streams/<id>` endpoint does not throw, but still returns
the existing definition. A new key `data_stream_exists` indicates
whether we are in this situation
* The UI clearly communicates to the user and doesn't try to do
additional requests
<img width="838" alt="Screenshot 2025-01-24 at 16 42 23"
src="https://github.com/user-attachments/assets/92cc5a82-2bb2-4d66-b47a-057ddcff5888"
/>
Trying to update ingest via the API will still result in an error.
Another weird behavior related to that was that if a dashboard is linked
to a stale classic stream, no definition is ever saved and the stream
disappears from the list when deleted, making the dashboard link
inaccessible. This PR introduces `ensureStream` which is called by the
dashboard APIs and makes sure the definition is there if dashboard links
exist. As a side effect, this makes sure that a user can't add dashboard
links to a stream they don't have access to - IMHO we should have done
that from the start.
This does not touch wired streams - for those, the data stream getting
deleted is a breach of contract. We should still handle it gracefully,
but in this case I think we should go another route and offer a button
in the UI to use the "resync" API to reconcile the state of the streams
layer and Elasticsearch. I will look into this on a separate PR.
## Summary
Search profiler checks to see if there are indices before allowing the
execution of a search to prevent a "there are no indices" error. This PR
makes this check more performant.
In large clusters, requesting a full list of indices can be slow (up to
4 seconds) and results in excess data transfer. The indices exist api
simply returns a boolean if an index is found and remains performant on
large clusters.
Fixes https://github.com/elastic/streams-program/issues/103
This PR adds a constant keyword `stream.name` field that functions
similar to the `data_stream.dataset` field.
It will allow us to clearly associate a document or a set of documents
with their streams and filter data per stream efficiently. It's also
used to validate that documents are sent properly to the root stream
instead of targeting specific child streams directly.
The `stream.name` field reports as `keyword` in the UI, but is actually
mapped per index template as a constant keyword set to the respective
value.
## Summary
Add MapsPage to the scout core to be re-used by others.
Add rudimentary docs to show how to run these tests.
Added a `waitForRender` method.
Add test id.
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co>
Co-authored-by: Nick Partridge <nick.ryan.partridge@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Provides the timerange in the fetch fields api. This:
- fixes the bug where the fields are not suggested when there are system
named params such as `_tstart` and `_tend`
- makes it more performant as now it checks for fields in the selected
timerange making it more performant (especially for data in the frozen
tiers)
<img width="834" alt="image"
src="https://github.com/user-attachments/assets/ec0e6f87-3149-4a3f-a620-d7eab6a852a2"
/>
Closes: #205826Closes: #205825
**Description**
Import entities input file upload box is missing label on entity store
page.
**Preconditions**
Security -> Manage ->Entity store page
**Steps to reproduce**
1. Open Entity store page
2. Run axe-core through the page
**Changes made**
1. added required `aria-label` attributes for mentioned places
**Screen**
<img width="1223" alt="image"
src="https://github.com/user-attachments/assets/29a76c2c-76f6-4bdc-b3f4-4feefc4009eb"
/>
## Summary
Adding script to discover Scout playwright tests in Kibana repo, will be
used to build CI pipeline step (running tests per plugin in a separate
worker for the start). We can also consider using it to decide if code
change should trigger only specific plugin tests to run.
Usage:
```
node scripts/scout.js discover-playwright-configs --searchPaths x-pack/platform/plugins/private/discover_enhanced
```
Output:
```
info Searching for playwright config files in the following paths:
info - x-pack/platform/plugins/private/discover_enhanced/**/ui_tests/{playwright.config.ts,parallel.playwright.config.ts}
info
info Discovered playwright config files in '1' plugins
info [discover_enhanced] plugin:
info - x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts
info - x-pack/platform/plugins/private/discover_enhanced/ui_tests/playwright.config.ts
```
More usage examples:
```
node scripts/scout.js discover-playwright-configs // by default will search in ['src/platform/plugins', 'x-pack/**/plugins'] and return all existing ones
node scripts/scout.js discover-playwright-configs --searchPaths x-pack/platform // platform ones under x-pack
node scripts/scout.js discover-playwright-configs --searchPaths x-pack/** // all under x-pack
```
## Summary
In 8.17 we have introduced `semantic_text`
https://github.com/elastic/kibana/pull/197007 which required dedicated
inference endpoint.
As we now have default `.elser-2-elasticsearch` inference endpoint
available we want to migrate it out, but it's not possible to just
override `inference_id` mapping for the Knowledge Base data stream, so
instead we decided to first update the mapping by adding
`search_inference_id` pointing to the `.elser-2-elasticsearch` (to make
sure the data is queryable without the dedicated endpoint). Then we
update the Data Stream mapping to use the default endpoint and after
that we rollover the DS index to make sure new index is created and new
inference endpoint is used for new Knowledge Base data ingestion.
Will add testing steps soon
## Summary
This PR introduces support for configuring the `timestamp` field for
entity store enablement.
By default, the `timestamp` field is set to `@timestamp`, but users can
opt to use `event.ingested` or another preferred value based on their
requirements.
### Entity Store API changes
#### Entity Store enable
```
POST kbn:/api/entity_store/enable
{
"timestampField": "event.ingested"
}
```
#### Result
```
{
"engines": [
{
"status": "started",
"type": "user",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "event.ingested"
},
{
"status": "started",
"type": "host",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "event.ingested"
},
{
"status": "started",
"type": "universal",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "event.ingested"
}
],
"status": "running"
}
```
```
POST kbn:/api/entity_store/enable
{
}
```
#### Result
```
{
"engines": [
{
"status": "started",
"type": "host",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "@timestamp"
},
{
"status": "started",
"type": "user",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "@timestamp"
},
{
"status": "started",
"type": "universal",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "@timestamp"
}
],
"status": "running"
}
```
Different entity types can have distinct `timestampField` values, as
described below:
For instance, the `host` entity uses `event.ingested` as its
`timestampField`, while other entities default to the `@timestamp`
field.
```
POST kbn:/api/entity_store/engines/host/init
{
"timestampField": "event.ingested"
}
POST kbn:/api/entity_store/engines/user/init
{
}
```
#### Result
```
{
"engines": [
{
"status": "started",
"type": "universal",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "@timestamp"
},
{
"status": "started",
"type": "host",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "event.ingested"
},
{
"status": "started",
"type": "user",
"indexPattern": "",
"filter": "",
"fieldHistoryLength": 10,
"timestampField": "@timestamp"
}
],
"status": "running"
}
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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)
### Testing steps
- Check out this PR branch.
- Start Kibana.
- Avoid enabling the Entity Store from the UI initially. Instead, enable
it via the API by following the steps outlined below.
```
DELETE kbn:/api/entity_store/engines/user
DELETE kbn:/api/entity_store/engines/host
GET kbn:/api/entity_store/status
All engines with the same timestamp Field
POST kbn:/api/entity_store/enable
{
"timestampField": "event.ingested"
}
# All engines with the same timestamp Field
POST kbn:/api/entity_store/enable
{
}
# Different entity with different timestamp Field
POST kbn:/api/entity_store/engines/host/init
{
"timestampField": "event.ingested"
}
POST kbn:/api/entity_store/engines/user/init
{
}
```
4. Afterward, you can test the functionality through the UI. First,
clear the entity data from the UI, then start the Entity Store. Note
that the UI currently does not offer a way to configure this parameter.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
A minimal version of the file upload tool which can be triggered via a
uiAction.
The trigger takes a callback to enable subsequent actions after the
upload. This callback receives information about the upload, the index
and data view created and information about the files:
```
{
"index": "test9",
"dataView": {
"id": "a870ef68-a624-4df1-9d5d-fa62b75dd297",
"title": ""
},
"files": [
{
"fileName": "farequote-tiny.csv",
"docCount": 20,
"fileFormat": "delimited"
},
{
"fileName": "farequote.csv",
"docCount": 86275,
"fileFormat": "delimited"
}
]
}
```
If `autoAddInference` is set with the name of an inference endpoint
(`autoAddInference: '.elser-2-elasticsearch'`) the tool with
automatically add a `semantic_text` to the mappings for tika files (pdf,
txt docx)
Currently embedded in the search app's home page and playground. In
playgroubnd, after upload is complete and the flyout closed, the newly
created index will be selected.
https://github.com/user-attachments/assets/0589fa02-fb0e-400b-8e74-1eb9a993c6ba
Multiple files can be uploaded at once. They must be of the same file
format and the mappings cannot clash.
If more than once file has the same field but they are of different
types, the files are considered incompatible.
<img width="612" alt="image"
src="https://github.com/user-attachments/assets/67307fd0-7d10-4eab-9e72-df133ebddcfe"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `bd40170` ->
`d04ee51` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
- Removed webcrawler endpoints
- Removes unused cloud_health endpoint
- Removes ent search node request handler
### 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
Resolves#188428
## Summary
- Add callout in serverless to indicate that initial data backfill is
limited to 7 days.
- If prevent data backfill is checked, transform will still use the SLO
delay for the filter range.
- If serverless and prevent data backfill is not checked, data backfill
is hard coded to 7 days, the lowest rolling time window option. Time
window will not be rounded down.
<img width="980" alt="Screenshot 2025-01-29 at 11 18 01 AM"
src="https://github.com/user-attachments/assets/b6481ef9-cc0e-4403-8309-50b6d8f37e70"
/>
## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### 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/packages/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
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## Summary
This PR adds the following parameters to the `INIT` engine API:
* `frequency`: the transform run frequency
* `timeout`: the timeout for the initial creation of the transform
* `docsPerSecond`: transform throttling option. See
[here](https://arc.net/l/quote/vxcmfnhh)
* `delay`: The transform delay duration. See
[here](https://arc.net/l/quote/mzvaexhv)
Coming soon
In addition, the PR adds these fields to the Saved Object with the
engine descriptor, as well as providing a migration with the appropriate
backfilling.
Finally, there are some utility function that were/are helpful in
working with objects.
## How to test
*NOTE*: Always make sure the security default data view exists. Easiest
way it to just navigate to some Security UI.
### Checking the new defaults
1. Initialize an engine via dev tools by calling: `POST
kbn:/api/entity_store/engines/<entity_type>/init {}`
2. Call `GET kbn:/api/entity_store/status`. This response should now
contain all the default optional values.
### Observing the parameters are being applied
1. Initialize an engine via the API. This time pass any of the `timeout,
frequency, delay and docsPerSecond` options in the request body.
2. Once the `status` changes to `started`, query the respective
transform: `GET
_transform/entities-v1-latest-security_<entity_type>_default`
3. Check that the parameters have been applied to the transform
### Checking Saved Object Migration
1. Check out `main`.
2. Initialize the store.
3. Query `GET kbn:/api/entity_store/status`. Note down the fields in the
engine object.
4. Check out this branch.
5. Restart kibana.
6. Query `GET kbn:/api/entity_store/status` again. Observe the new
fields have been added and backfilled
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
