## 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
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12007))
These changes add the attack discovery schedules management table.
https://github.com/user-attachments/assets/619ad1d6-d919-4a8d-b743-6a73fbfbf318
## Key changes
* UI side API handlers
* Create schedule workflow
* Schedules table
* Enable schedule from the table
* Disable schedule from the table
* Delete schedule from the table
* Pagination and sorting in find schedules API
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
This PR passes the current sample documents to the default form state
generation for new processors to pick a good default field.
The logic that's actually employed for `dissect` and `grok` is the
following:
* Go through all docs and order string fields occurring by how many
values they have
* Pick the top one from a list of "well known" fields that probably make
sense (in case of a tie, go by a the ordering of the well known fields)
* If no field is found this way, just leave it empty - this still shows
the full table and the user can pick the field they care about
Especially for otel this should be helpful.
## Summary
This PR better separates the request building logic in the detection
engine from query building logic, removes outdated error checking logic,
updates the `singleSearchAfter` `search` call to no longer use the
legacy `meta: true` param, and improves search response type inference.
Closes: https://github.com/elastic/kibana/issues/217511
**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.
## Summary
When the datatable comes with empty results the visualization fails with
bad way
<img width="396" alt="image"
src="https://github.com/user-attachments/assets/b4e266d7-edbd-452b-9192-84c957fe98db"
/>
With the fix
<img width="756" alt="image"
src="https://github.com/user-attachments/assets/d061d29e-9246-432a-944b-308b88d161e7"
/>
How to replicate:
- Create a field ES|QL control with 2 values (extension and geo.dest).
You can do it with multiple ways. I created with typing `FROM
kibana_sample_data_logs | STATS count = COUNT(*) BY` and then `Create
control`.
- Use the variable in another panel with query: `FROM
kibana_sample_data_logs | WHERE ??field == "css" | KEEP extension` (The
control value should be in the extension). This will work
- Select the second field (geo.dest). This will return an empty query
and will break the table viz.
### 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
