## Summary
Ensure Enable Button Considers Disabled State of Risk Score & Entity
Store. Previously only used the checked state of the toggle.
### Reproduce the Issue
Steps, as [per bug
ticket:](https://github.com/elastic/kibana/issues/209242#issue-2826951496)
1. Kibana version 8.16.0 or above should exist
2. Navigate to the Dashboards tab under Security
3. Select Entity Analytics dashboard
4. Click on the enable button and enable risk score
5. Disable the options for Entity store
6. Then again select the enable button for Entity store
7. Disable the enable button
8. Observe the Enable button is still enabled
### After Issue Solved
Same steps as above, but should show the warning and disable the button.
#### Videos
Videos show when either riskScore or entityStore is enabled, and the
other is unchecked, the warning should show and the button should be
disabled.
https://github.com/user-attachments/assets/236f9e69-f810-4116-9948-38fd27d4d945https://github.com/user-attachments/assets/2971e845-5d46-4eac-997a-79b3b17922c0
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- addresses https://github.com/elastic/kibana/issues/179767
- ignore_fields tests run as expected on basic/essentials license, so
moved to that tier
- moves the rest of files in `general_logic` set of tests to basic
level, apart from synthetic source tests that requires platinum(trial)
license
## Summary
- addresses https://github.com/elastic/kibana/issues/211003
- marks syntax, data verification(missing indices or wrong type of
index), license errors as user errors to avoid triggering response-ops
Serveless SLO
### Testing
create ES|QL rule with invalid query syntax through API call: `from
YOUR_INDEX metadata _id |`
run rule, observe error
use any debugging method to check that in
`x-pack/platform/plugins/shared/alerting/server/monitoring/rule_result_service.ts`
alerting method `addLastRunError` reports userError
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
* Remove some old paths pointing to `packages/kbn-pm` (no longer
exists).
* ~Fix group and visibility for `@kbn/streams-app-wrapper-plugin`~.
(done in https://github.com/elastic/kibana/pull/212210)
* Update `scripts/relocate` logic with latest enhancements.
* Convert `@kbn/observability-synthetics-test-data` folder name to
camel-case (messes up with pre-commit hook).
## Summary
This adds a read version of the default Search privilege. This will make
sure that viewer users don't land on a 403 error when logging into a
Search solution.
Optimizing the experience for the viewer role will be a separate task.
## Summary
The `/packages` folder at the root of the Kibana repository used to
contain a lot of packages.
In the context of SKA, they have been gradually moved to various
locations:
* `src/platform/packages`
* `x-pack/platform/packages`
* `src/core/packages`
Currently, only `devOnly: true` packages are left in this folder. This
comprises libraries for CLI scripts as well as testing utilities.
With this PR, we are moving ~half of these packages under
`src/platform/packages/(private|shared)/`.
In particular, we are moving those packages that are being used from
platform and/or solutions.
Since they are `"devOnly": true`, this means they are ONLY used from
tests, cypress tests, storybook configs, ./scripts/ folders inside some
modules, or other non-prod-time logic. Nonetheless, they are effectively
referenced from platform and/or solutions code, hence I decided they
should be placed under `platform` folders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds logging of request ID in SAML provider. Having the request
ID assists in troubleshooting by providing a means to correlate
authentication attempts across Kibana and ES logs.
The full request ID is logged because it is not considered sensitive
information - it is a temporary identifier that is only relevant for a
single authentication attempt.
## Summary
It closes#210712
This PR adds the following features:
- Introduces a new `status` API for the asset inventory, which returns
the status of the entity store, including statuses like
`insufficient_privileges`, `disabled`, `initializing`, `ready`, and
`empty`.
- Implements a mechanism to check the current status of the host entity
store and processes the transform component metadata.
It also introduces the following changes:
- Implemented the use of the host entity store to support the new status
API while awaiting the readiness of the 'generic' entity store.
- Added a `metadata` field to the entity store stats object and used it
to add additional metadata from the transform components.
- Replaced the retrieval of the entity store ID with the inclusion of
`stats.id` from the transform stats.
- Unit tests were added to ensure that the new API and status behavior
are functioning correctly, covering all possible states and edge cases.
### Key Changes:
- **API Changes**: A new `status` endpoint was added to query the asset
inventory's status, leveraging the host entity store for now.
- **Metadata Changes**: The `metadata` field was added to the entity
store stats to include transform-related metadata, such as
`documents_processed` and `trigger_count`.
- **Testing**: New unit tests were added to validate the behaviour of
the status API, including scenarios like insufficient privileges, entity
store installation, and document processing status.
### How to test it locally
To test it locally, execute the following in the Kibana dev tools:
```
GET kbn:/api/asset_inventory/status
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Wraps the logos in our service provider list in an avatar so they are
visible in dark mode.
This does not change the selected state for a provider. These logos will
still look poorly in dark mode, but this seemed like a larger effort
(perhaps someone can help make that more seamless).
We could also just remove the logo when selected. The logos are
beneficial when finding a preferred service, but possibly less so once
I've chosen one.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Samiul Monir <samiul.monir@elastic.co>
## Summary
Implements an exponential backoff retry strategy when the LLM API throws
rate limit (`429`) errors.
### Backoff implementation
- The `run` method from the `RuleMigrationsTaskClient` has been moved to
the new `RuleMigrationTaskRunner` class.
- The settings for the backoff are defined in this class with:
```ts
/** Exponential backoff configuration to handle rate limit errors */
const RETRY_CONFIG = {
initialRetryDelaySeconds: 1,
backoffMultiplier: 2,
maxRetries: 8,
// max waiting time 4m15s (1*2^8 = 256s)
} as const;
```
- Only one rule will be retried at a time, the rest of the concurrent
rule translations blocked by the rate limit will await for the API to
recover before attempting the translation again.
```ts
/** Executor sleep configuration
* A sleep time applied at the beginning of each single rule translation in the execution pool,
* The objective of this sleep is to spread the load of concurrent translations, and prevent hitting the rate limit repeatedly.
* The sleep time applied is a random number between [0-value]. Every time we hit rate limit the value is increased by the multiplier, up to the limit.
*/
const EXECUTOR_SLEEP = {
initialValueSeconds: 3,
multiplier: 2,
limitSeconds: 96, // 1m36s (5 increases)
} as const;
```
### Migration batching changes
```ts
/** Number of concurrent rule translations in the pool */
const TASK_CONCURRENCY = 10 as const;
/** Number of rules loaded in memory to be translated in the pool */
const TASK_BATCH_SIZE = 100 as const;
```
#### Before
- Batches of 15 rules were retrieved and executed in a `Promise.all`,
requiring all of them to be completed before proceeding to the next
batch.
- A "batch sleep" of 10s was executed at the end of each iteration.
#### In this PR
- Batches of 100 rules are retrieved and kept in memory. The execution
is performed in a task pool with a concurrency of 10 rules. This ensures
there are always 10 rules executing at a time.
- The "batch sleep" has been removed in favour of an "execution sleep"
of rand[1-3]s at the start of each single rule migration. This
individual sleep serves two goals:
- Spread the load when the migration is first launched.
- Prevent hitting the rate limit consistently: The sleep duration is
increased every time we hit a rate limit.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
- Resolves#211049
- Adds the ability for a user to create an API Key in synthetics
settings that applies to specified space(s)
- Reuses existing spaces combo box from private locations, enhances the
component to incorporate a generic interface and help text prop to
enable additional uses
- Modifies functionality of Generate API Key button to consider a blank
spaces field before creating the key
- Currently, in private locations, if the spaces field is blank, the
save button has no functionality, so this was copied here.
### Release Notes
Adds the ability for a user to create an API Key in synthetics settings
that applies only to specified space(s)
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `d74b1fd` ->
`0801a43` |
---
### 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://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Fixes the resource badge rendering so that the formatting does not
output html when the page has a filter applied to it. Badges will no
longer have `<mark>` applied to the text.
<img alt="Resource badge fix 2025-02-20 114954"
src="https://github.com/user-attachments/assets/f92c3c5d-152f-42c5-8159-ba34f6cd174e"
/>
## How to test
- Setup an edge-oblt cluster to point to in `kibana.dev.yml`, or create
a data view with an id that contains `apm_static_data_view_id`, so for
example `apm_static_data_view_id_default`. Then, add the following as
well to the `kibana.dev.yaml`:
```yaml
discover.experimental.enabledProfiles:
- traces-data-source-profile
```
- Go to Discover page with the data view enabled
- Add a filter for one of the resource badge fields: service.name,
event.outcome
- The formatting on the badge should not show `<mark>` around the text
label, and instead only on the flyout, will the filtered fields show the
marked formatting.
## Summary
Remove overlapping Synthetics tests from the `api_integration` folder.
Tests are kept in the original directory if one of the following is true
A.) They haven't yet been moved to the deployment agnostic
B.) They create custom users and roles (this provides some coverage for
real stateful privileges, which the deployment agnostic directory mocks
with api keys),
C.) They deal directly with api key privileges
D.) They would fail entirely in deployment agnostic (for example, params
which fails in serverless, both MKI and local serverless).
Additionally, some files in the `deployment_agnostic` folder were split
in order to provide some level of coverage for public locations. Files
which contain coverage for public locations are skipped in cloud and
MKI, as they would fail there due to not having the mock location
available.
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
## Summary
This PR improves how **Synthtrace** resolves the Kibana URL when only
`--target` (Elasticsearch) is provided or when neither `--target` nor
`--kibana` is specified. The CLI now attempts to **automatically
discover** the appropriate URLs based on the provided arguments.
Some adjustments were made to improve this discovery process, especially
when running **locally in Serverless mode**, where Kibana may be using
`http`, while Elasticsearch (ES) is on `https`. Additionally,
self-signed certificates do not work with the IP address `127.0.0.1`, so
this PR defaults to `localhost` and warns the user if `127.0.0.1` is
detected in Serverless mode.
### **Improvements**
- If either of `--target` or `--kibana` or neither provided, the CLI
attempts to **discovers the URLs** dynamically now in both Stateful and
Serverless.
- Defaults to `localhost` instead of `127.0.0.1` to avoid SSL
certificate issues.
- Provides a **clear error message and hint** when Kibana and ES use
different protocols (http vs https) and either or both are unreachable.
### **Expected Behavior After This PR**
These commands should now work **seamlessly** in both **local Stateful**
and **Serverless** modes:
```sh
✗ node scripts/synthtrace simple_logs
```
For **Serverless mode**, these also work:
```sh
✗ node scripts/synthtrace simple_logs --kibana=http://elastic_serverless:changeme@localhost:5601
```
```sh
✗ node scripts/synthtrace simple_logs --target=https://elastic_serverless:changeme@localhost:9200 --kibana=http://elastic_serverless:changeme@localhost:5601
```
### **(Side Note) Serverless Kibana with SSL Disabled**
However, the following command will **fail** with an error message if
Kibana is running without SSL, while Elasticsearch is using `https`:
```sh
✗ node scripts/synthtrace simple_logs --target=https://elastic_serverless:changeme@localhost:9200
```
#### **Error Output:**
```sh
Loading scenario from kibana/packages/kbn-apm-synthtrace/src/scenarios/simple_logs.ts
Error: Could not connect to Kibana. request to https://elastic_serverless:changeme@localhost:5601/ failed, reason: write EPROTO 400882F501000000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:355:
If your Kibana URL differs, consider using the '--kibana' parameter to customize it.
```
**Solution:**
If you must have to provide `--target` (non defaults), also provide
`--kibana` or start Kibana with SSL enabled.
```sh
✗ yarn start --serverless=oblt --ssl
```
## Summary
In #211918 I added config validation check to skip run if there are no
tests in playwright config.
It turned out that Playwright init reporters even when `--list` command
is passed and no tests are executed, that lead to Scout reports being
loaded and then causing reporter error when the other command runs the
tests:
```
proc [playwright] info Calling save with destination: /Users/dmle/github/kibana/.scout/reports/scout-playwright-9518363d47816953
proc [playwright] ERROR Error: Save destination path '/Users/dmle/github/kibana/.scout/reports/scout-playwright-9518363d47816953' already exists
proc [playwright] at ScoutEventsReport.save (/Users/dmle/github/kibana/packages/kbn-scout-reporting/src/reporting/report/events/report.ts:56:13)
proc [playwright] at ScoutPlaywrightReporter.onEnd (/Users/dmle/github/kibana/packages/kbn-scout-reporting/src/reporting/playwright/events/playwright_reporter.ts:277:19)
proc [playwright] at ReporterV2Wrapper.onEnd (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/reporterV2.js:91:165)
proc [playwright] at /Users/dmle/github/kibana/node_modules/playwright/lib/reporters/multiplexer.js:71:117
proc [playwright] at wrapAsync (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/multiplexer.js:112:18)
proc [playwright] at Multiplexer.onEnd (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/multiplexer.js:69:31)
proc [playwright] at InternalReporter.onEnd (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/internalReporter.js:77:12)
proc [playwright] at finishTaskRun (/Users/dmle/github/kibana/node_modules/playwright/lib/runner/tasks.js:90:26)
proc [playwright] at runTasks (/Users/dmle/github/kibana/node_modules/playwright/lib/runner/tasks.js:73:10)
proc [playwright] at Runner.runAllTests (/Users/dmle/github/kibana/node_modules/playwright/lib/runner/runner.js:72:20)
proc [playwright] at runTests (/Users/dmle/github/kibana/node_modules/playwright/lib/program.js:211:18)
proc [playwright] at t.<anonymous> (/Users/dmle/github/kibana/node_modules/playwright/lib/program.js:54:7)
```
The simplest solution is to explicitly disable Scout reporter for config
validation command.
This PR moves the `streams` and `streams_app` plugins into platform so
they can be used in other solutions in the future. This PR is not
actually making it available in other solutions yet since we are still
discussing the release plans.
## Inlined helpers
As discussed before, this PR inlines a couple simple helper methods for
query building, time zone normalization, a header portal helper and a
data plugin timefilter state react integration hook as there is no good
place for these outside of the observability solution.
## streams_app plugin
The streams_app plugin is not actually registering anything, instead it
simply exports a component that renders the app which needs to be
consumed by another plugin to turn it into a registered app - for now,
`observability_streams_wrapper` takes over this job.
## observability_streams_wrapper plugin
While 99% of the streams logic is moved into the
`platform/shared/streams_app`, two bits are left behind in
`observability_streams_wrapper`:
* The actual app registration
* Integration with the observability_shared `PageTemplate` component
Once we decide streams should be displayed outside of the observability
solution, it's probably not necessary anymore to decouple app definition
and registration like this because it will always be visible no matter
the solution. Once this is the case, the navigation registration can be
moved into the central `observability` plugin, like it's handled with
other apps like infra.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/207852
## Summary
This PR migrates all `*.scss` files in the Links plugin to Emotion.
Testing should simply verify that this PR does not introduce any style
changes.
### 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 scenario
- [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
Any risks associated with this PR are purely cosmetic, since it contains
exclusively style-related changes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Similar to other place which use this popover, let's try force click to
fix flaky tests
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
