## 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>
Fixes https://github.com/elastic/kibana/issues/212902
## Summary
This PR fixes the logic for finding folding ranges by ignoring
opening/closing markers inside triple-quote strings.
**How to test:**
Verify that the `script` field in the following request is folded
correctly:
```
POST _ingest/pipeline/_simulate
{
"pipeline": {
"processors": [
{
"script": {
"source":
"""
for (field in params['fields']){
if (!$(field, '').isEmpty()){
def value = $(field, '');
def hash = value.sha256();
// Now we need to traverse as deep as needed
// and write to that field
// because we do not have a simple
// set operation available
"SCRIPT": parts = field.splitOnToken('.');
}
}
""",
"params": {
"fields": [
"user.name",
"geo.city",
"does.not.exist",
"this.is.quite.a.deep.field"
]
}
}
}
]
}
}
```
Note: The logic is for finding the ranges is best-effort without
compromising performance. We currently iterate through each line in the
text and use regex, but there are some cases which are not covered by
this logic; for example, opening parenthesis, followed by a string in
the same line would not be foldable. In order to cover all cases
correctly, we would need to iterate through every single character, but
that would make the logic much more complex and might affect performance
if we have a lot of text in the editor, as these folding ranges are
computed on every change in the editor.
OTel is expected to become more common over time. This PR adds a
synthtrace scenario to send sample otel logs to an otel data stream.
This helps testing whether Discover, Streams and so on function
correctly for this category of data.
Closes: #216147
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Added` aria-labelledby={flyoutTitleId} `for mentioned places
