## Summary
Relates to https://github.com/elastic/kibana/issues/181995
This PR updates the examples to include availability information and
another description.
Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
## Summary
This PR is to hide K8S so User won't be able to access K8S Dashboard via
navigating to it from the page or by direct URL,
also deleting Cypress tests related to this
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [chromedriver](https://togithub.com/giggio/node-chromedriver) |
devDependencies | major | [`^130.0.4` ->
`^131.0.0`](https://renovatebot.com/diffs/npm/chromedriver/130.0.4/131.0.0)
| `131.0.1` |
---
### Release Notes
<details>
<summary>giggio/node-chromedriver (chromedriver)</summary>
###
[`v131.0.0`](https://togithub.com/giggio/node-chromedriver/compare/130.0.4...131.0.0)
[Compare
Source](https://togithub.com/giggio/node-chromedriver/compare/130.0.4...131.0.0)
</details>
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
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>
Co-authored-by: Jon <jon@elastic.co>
## Summary
Prevents an initial re-render when the `project` navigation style is set
(serverless and new solution nav for stateful).
This re-render was affecting all the top-level pages in Security
Solution.
---------
Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co>
Closes https://github.com/elastic/kibana/issues/194489
PR adds new `PublishesRendered` interface. Embeddables can implement
this interface to provide feedback when rendering is complete.
PR updates ReactEmbeddableRender phase tracking logic to include check
for `PublishesRendered` value when interface is implemented.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Sends "Rule migration complete" notifications from anywhere in the
Security Solution app, whenever a rule migration finishes, with a link
to the migrated rules.
The polling logic has been encapsulated in the new
`siemMigrations.rules` service so the request loop is centralized in one
place. The value updates are broadcasted using the `latestStats$`
observable.
It will only keep requesting while there are _running_ migrations and
will stop automatically when no more migrations are _running_.
The reusable `useLatestStats` hook has been created for the UI
components to consume. This approach allows multiple components to
listen and update their content automatically with every rule migration
stats update, having only one request loop running.
The polling will only start if it's not already running and only if the
SIEM migration functionality is available, which includes:
- Experimental flag enabled
- _Enterprise_ license
- TODO: feature capability check (RBAC
[issue](https://github.com/elastic/security-team/issues/11262))
The polling will try to start when:
- Automatically with the Security Solution application starts
- The first render of every page that uses `useLatestStats` hook.
- TODO: A new migration is created from the onboarding page
([issue](https://github.com/elastic/security-team/issues/10667))
Tests will be implemented in [this
task](https://github.com/elastic/security-team/issues/11256)
## Example
A Rule migration finishes while using Timeline in the Alerts page:
https://github.com/user-attachments/assets/aac2b2c8-27fe-40d5-9f32-0bee74c9dc6a
**Resolves: https://github.com/elastic/kibana/issues/200904**
## Summary
This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.
## Details
Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.
A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.
The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR adds a synthtrace scenario for the main logs streams endpoint
called `slash_logs`. It can be invoked like this:
```
node scripts/synthtrace.js slash_logs --live --kibana=http://elastic:changeme@localhost:5601 --target=http://elastic:changeme@localhost:9200 --liveBucketSize=1000
```
## Changes on synthtrace
I had to adapt a couple things:
* Add the `--liveBucketSize` flag because it's really annoying to wait
for a minute to see whether data gets processed correctly
* Extend the existing log mock module that's also used for the
unstructured logs scenario in a couple ways
* Add the ability to route directly to an index by adding `_index` to a
document (otherwise it will use the DSNS)
## Changes on streams
I fixed a couple things I realized were broken:
* Check whether a field exists before accessing it in the routing
condition (otherwise it rejects the document)
* Update ES objects in the right order - if the routing is put in place
before the receiving child data stream is ready, it will auto-create an
index with the wrong mapping
* Allow to not specify a condition for a child - in this case it's not
routing to this child
* Set `subobjects: true` for now - otherwise fields are not indexed
properly, I think this is an Elasticsearch bug, I will follow up on this
with the Elasticsearch team
* Set `dynamic: false` - that somehow got lost in refactorings
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to obs ai assist team
Contributes to: #192979
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Creates the Streams app plugin, which renders UI for managing streams
(see https://github.com/elastic/kibana/pull/198713).
Additional changes in this PR:
- The menus were updated to conditionally add a link to the Streams app.
The Streams plugin itself returns a status$ observable which signals if
Streams have been enabled. This value is used to conditionally render
the link in the various flavors of menus.
- There's a small change in the ES types to allow for ordered params in
ES|QL (vs named params)
- `@kbn/server-route-repository` was updated to be able to override
`access` (instead of only inferring it from the endpoint name).
Additionally, we now allow all route options by default.
- `@kbn/typed-react-router-config` now also exports a `useBreadcrumbs`.
This was copied over from the APM implementation.
- the signature of the `esql` method in
`ObservabilityElasticsearchClient` was updated to separate processing
options from options that are sent over to the _query endpoint.
---------
Co-authored-by: Chris Cowan <chris@elastic.co>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[dependency-cruiser](https://github.com/sverweij/dependency-cruiser/tree/main)
is used for building dependency graph.
### Show all dependencies for a specific package/plugin or directory
#### Run for all plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins -o ./tmp/deps-result-all.json
```
#### Run for single plugin
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -o ./tmp/deps-result-single.json
```
#### Run for multiple plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution x-pack/plugins/security -o ./tmp/deps-result-multiple.json
```
#### Run for `x-pack/packages`
```bash
bash scripts/dependency_usage.sh -p x-pack/packages -o ./tmp/deps-packages-1.json
```
#### Run for `packages`
```bash
bash scripts/dependency_usage.sh -p packages -o ./tmp/deps-packages-2.json
```
#### Benchmark
| Analysis | Real Time | User Time | Sys Time |
|-----------------------|-------------|-------------|------------|
| All plugins | 7m 21.126s | 7m 53.099s | 20.581s |
| Single plugin | 31.360s | 45.352s | 2.208s |
| Multiple plugins | 36.403s | 50.563s | 2.814s |
| x-pack/packages | 6.638s | 12.646s | 0.654s |
| packages | 25.744s | 39.073s | 2.191s |
#### Show all packages/plugins within a directory that use a specific
dependency
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins/security_solution
```
---
#### Show all packages/plugins within a directory grouped by code owner
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins -g owner
```
---
#### Group by code owner with adjustable collapse depth for fine-grained
grouping
**Fine-grained grouping**:
```sh
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 4
```
**Collapsed grouping**: groups the results under a higher-level owner
(e.g., `security_solution` as a single group).
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 1
```
---
#### Show all dependencies matching a pattern (e.g., `react-*`) within a
package
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -d 'react-*' -o ./tmp/result.json
```
### Checklist
- [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
__Related: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR filters the fields containing `@` in date type from `script`
processor.
## Before this PR
```json
{
"script": {
"tag": "script_convert_array_to_string",
"description": "Ensures the date processor does not receive an array value.",
"lang": "painless",
"source": "if (ctx.varonis?.varonis_alerts?.@timestamp != null &&\n ctx.varonis.varonis_alerts.@timestamp instanceof ArrayList){\n ctx.varonis.varonis_alerts.@timestamp = ctx.varonis.varonis_alerts.@timestamp[0];\n}\n"
}
},
{
"date": {
"if": "ctx.varonis?.varonis_alerts?.@timestamp != null",
"tag": "date_processor_varonis.varonis_alerts.@timestamp",
"field": "varonis.varonis_alerts.@timestamp",
"target_field": "event.start",
"formats": [
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'",
"ISO8601"
]
}
},
```
## After this PR
```json
"date": {
"if": "ctx.varonis?.varonis_alerts?.@timestamp != null",
"tag": "date_processor_varonis.varonis_alerts.@timestamp",
"field": "varonis.varonis_alerts.@timestamp",
"target_field": "event.start",
"formats": [
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'",
"ISO8601"
]
}
},
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
## Summary
Closes#201346
This PR adds a `dat` dev script, which lets you easily run APM
deployment-agnostic tests, as we already do with `api` tests.
## Examples
Run only server with stateful config
```sh
node x-pack/plugins/observability_solution/apm/scripts/test/dat --stateful --server
```
Run only runner with stateful config
```sh
node x-pack/plugins/observability_solution/apm/scripts/test/dat --stateful --runner
```
Run everything with serverless config
```sh
node x-pack/plugins/observability_solution/apm/scripts/test/dat --serverless
```
More information
[here](https://github.com/elastic/kibana/pull/201351/files#diff-5ca943bbe3962fc31cce510407cc1563a959b0fdb9cb52619f57e1f182a9751a)
---------
Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/201531
This PR skips `Transaction groups alerts when data is loaded with avg
transaction duration alerts returns the correct number of alert counts`,
which is inside
`x-pack/test/api_integration/deployment_agnostic/apis/observability/apm/transactions/transactions_groups_alerts.spec.ts`
file, as it's failing on MKI.
Closes https://github.com/elastic/kibana/issues/200769
## Summary
This PR is a follow-up to https://github.com/elastic/kibana/pull/199854
and it adds the following code improvements:
- Replaces Mappings-editor-context-level property `hasEnterpriceLicense`
with plugin-context-level `canUseSyntheticSource` property
- Adds jest tests to check if the synthetic option is correctly
displayed based on license
- Improves readability of serializer logic for the source field
**How to test:**
The same test instructions from
https://github.com/elastic/kibana/pull/199854 can be followed with a
focus on checking that the synthetic option is only available in
Enterprise license.
