## Summary
This PR adds new config option `defaultSolution`
(`xpack.spaces.defaultSolution`) which lets you specify a default
solution, similar to the way cloud plugin does it.
Addresses: #213144
## Summary
These 2 configs for all solutions take 35-39 minutes:
```
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group5.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group6.ts
```
I added 4 additional groups under each solution and relocated some
configs to split original runtime by ~3:
```
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group9.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group10.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group11.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group12.ts
```
It should help balancing configs better and retry failed ones faster.
After this PR groups runtime
|config path| runtime |
| ------------- | ------------- |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group5.ts|
16m 15s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group6.ts|
18m 7s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group9.ts|
12m 7s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group10.ts
| 16m 13s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group11.ts|
14m 3s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group12.ts|
17m 47s |
## Summary
Just had some fun and made fp-ts available in the shared bundle, with
support for partial imports.
Changes in this PR:
* aligned `fp-ts` direct imports to the format: `fp-ts/<module>`
* Mapped the direct imports into the shared bundle re-using the same
`fp-ts` module under the hood
Closes#213943
## Summary
This PR ensures the service name is always encoded in the APM UIs. It's
a follow-up of https://github.com/elastic/kibana/pull/215031 and aims to
find a better solution to the problem:
- Add the encoding directly to `formatRequest` as suggested there
- I saw that there are many places where we use legacy Url builders, so
I will try to replace them where possible and use
apm router link method where the path is encoded
([ref](7158e0201b/src/platform/packages/shared/kbn-typed-react-router-config/src/create_router.ts (L184-L185)))
- The PR includes the changes to address the issue above:
- Replaced and removed `LegacyAPMLink`
- Refactored `useAPMHref` to support encoding (and extracted and test
the encoding logic)
- Example usage:
- Before:
```js
useAPMHref({
path: `/services/${serviceName}/.....`,
persistedFilters,
});
```
- After:
```js
useAPMHref({
path: '/services/{serviceName}/.......}',
pathParams: { serviceName },
persistedFilters,
});
```
- Used the APM router link method as much as possible
## Testing
- Run `node scripts/synthtrace trace_with_service_names_with_slashes.ts
--clean --live --uniqueIds --live`
- Go to service inventory and click the links:
https://github.com/user-attachments/assets/fcd4fbfc-4125-4cc8-9b00-53c5f375423f
## Summary
Redo of https://github.com/elastic/kibana/pull/193471
Closes https://github.com/elastic/security-team/issues/8644
> Fixes a bug where importing a rule fails with a connector into a space
where (1) the connector already exists, and (2) the existing connector
was exported and re-imported from another space. The import logic in
this scenario effectively tries to convert the action ID on the rule
import twice. The second conversion attempt tries to use the old action
ID to look up the correct new action ID in a map, however, in this test
scenario the action ID has already been updated by legacy SO ID
migration logic and there is no map entry with the new ID as a key. The
result is that the second attempt sets the action ID to undefined,
resulting in an import failure.
The root cause of the bug is that we have two different places in the
rule import logic where action IDs are migrated. The first ID migration
was done by `migrateLegacyActionsIds` prior to importing rule actions,
and the second migration was done by `importRuleActionConnectors` after
importing the actions. `importRuleActionConnectors` used a lookup table
to convert old IDs to new IDs, but if the connector already existed and
had an `originId` then the rule action would already be migrated by
`migrateLegacyActionsIds`. The lookup table used by
`importRuleActionConnectors` does not have entries for migrated IDs,
only the original IDs, so in that case the result of the lookup is
`undefined` which we assign to the action ID.
This PR reworks the logic to create a clean separation between action
and rule import. We now import the connectors first, ignoring the rules,
then migrate action IDs on the rules afterwards. This handles connectors
changing IDs in any way, either through the 7.x->8.0 migration long ago
or IDs changing on import if there are ID conflicts. Only after the
connectors are imported and rule actions are migrated do we then verify
if each rule action references a connector ID that actually exists with
the new `checkRuleActions` function, replacing
`checkIfActionsHaveMissingConnectors` and related functions that were
also buggy.
Finally, as a nice side effect this rework removes "rule action
connector missing" errors out of the `action_connector_errors` part of
the response. `action_connector_errors` is reserved for errors importing
connectors specifically. If a rule action is missing a connector and
therefore we don't import the rule, that's a rule error and it's
represented in the `errors` part of the response. Since the shape of the
response is not changing, I don't consider this a breaking change but
rather a bug fix.
## Repro Steps
Repro Steps
1. Download the export file below and change the extension back to
.ndjson from .json (github does not allow .ndjson files
[rules_export.json](https://github.com/user-attachments/files/17065272/rules_export.json)
2. Import the rule and connector into a space (default is fine)
3. Create a new space
4. Import the rule and connector into the new space
5. Import the rule and connector into the new space again, but check the
`Overwrite existing connectors with conflicting action "id"` box.
Observe the failure.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Enables the Trace section for the summary tab in the Traces Doc Viewer.
This PR focuses on just bringing the section with the widget, not for
adjusting the widget styles/look to be closer to the intended designs.
That is for follow-up work.
Closes#217067
## How to test
* Add the following to your `kibana.dev.yml`:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Ensure you are on an Observability root profile space
* Go to Discover, use or create a Data View profiles targetting
`traces-*` (such as `remote_cluster:traces-*`).
* Click on a span/transaction to expand the doc viewer
* The trace waterfall section should be present on the summary tab.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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/216398
### Checklist
This test fails because it tests ES 9.0 with kibana 8.19 but this is not
compatible for field controls (ES changed the backend implementation in
8.19 and 9.1)
## 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>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base-fips | digest | `0135014` ->
`b6d3d24` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwiY2k6YnVpbGQtZG9ja2VyLWZpcHMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Brad White <Ikuni17@users.noreply.github.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `c56628d` ->
`1c7f5aa` |
---
### 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>
Co-authored-by: Brad White <Ikuni17@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
Fixes image paths to work with docs-assembler.
Notes for the reviewer:
* I was not able to get images in reference, extend, or release-notes to
work using the `:::{image}` syntax because it seems to resolve
differently than the Markdown `![]()` syntax. We should address this in
docs-builder, but in order to get images working as soon as possible,
I've used Markdown syntax and left us a `TO DO` in a code comment to add
back the `screenshot` class where applicable.
* Can you please add the appropriate labels needed for backporting?
## 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>
