## Summary
Remove run soon for sync private location task !!
It's not needed since it's a scheduled task running every 10 minutes .
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes#222112
## Summary
I used the Machine Learning section as a guide because it has a similar
mix of "items" and "groups" but is presented correctly in the UI, so by
making the "apm" section look the same, it is fixed.
<img width="496" alt="Screenshot 2025-05-30 at 4 08 24 PM"
src="https://github.com/user-attachments/assets/e6a9d659-df58-4ec5-bf2d-2584fa2fe0d2"
/>
## Context
Machine Learning nav:
<img width="515" alt="Screenshot 2025-05-30 at 3 48 17 PM"
src="https://github.com/user-attachments/assets/25b7c1e4-8a99-43a4-be75-3299bd5412bd"
/>
| Top-level Group | Items | Sub-groups |
| :-- | :-- | :-- |
| Machine Learning | Overview, Data Visualizer | Anomaly Detection, Data
Frame Analytics, AIOps Labs |
| Applications | Service Inventory, Traces, Dependencies, Settings |
Synthetics |
I noticed the structure of these two sections was slightly different.
The machine learning one looks like this (i18n functions removed for
readability):
```ts
{
id: 'machine_learning-landing',
renderAs: 'panelOpener',
title: 'Machine Learning',
children: [
{
children: [
{ link: 'ml:overview' },
{ link: 'ml:dataVisualizer' },
],
},
{
id: 'category-anomaly_detection',
title: 'Anomaly detection',
breadcrumbStatus: 'hidden',
children: [
{ link: 'ml:anomalyExplorer' },
{ link: 'ml:singleMetricViewer' },
],
},
]
}
```
whereas "Applications" included the synthetics sub-section further
nested in, as a sibling to the other items:
```ts
{
id: 'apm',
title: 'Applications',
renderAs: 'panelOpener',
children: [
{
children: [
{
link: 'apm:services',
title: 'Service Inventory',
},
{ link: 'apm:traces' },
{ link: 'apm:dependencies' },
{ link: 'apm:settings' },
{
id: 'synthetics',
title: 'Synthetics',
children: [
{
title: 'Overview',
id: 'synthetics-overview',
link: 'synthetics:overview',
breadcrumbStatus: 'hidden',
},
```
When I moved the Synthetics sub-section out of the children > children
section and into children, the nav rendered correctly.
I'm not sure if this is expected behavior, [there is some logic to
confirm](0fcc9a39ba/src/platform/packages/shared/shared-ux/chrome/navigation/src/ui/components/panel/default_content.tsx (L75))
sections are "all items" OR "all groups" but ours seemed to be a mix,
but didn't fail.
Currently we use a search with a `top_hits` aggregation to get the
alerts filtered with the scoped queries of the active maintenance
windows. But since `top_hits` aggregation has a fixed limit of 100 hits
we cannot use our max alerts limit to get all the alerts an execution
can generate.
This PR replaces `search` with `msearch` and removes the aggregation
from the search query so we can use the maxAlerts limit for the response
size.
Resolves https://github.com/elastic/kibana/issues/208459
## Summary
Unskips flaky test that was failing with the error below. This PR
updates the test to wait until the task is finished running before
checking that the status is marked as `unrecognized`.
```
Error: expect(received).toBe(expected) // Object.is equality
Expected: "unrecognized"
Received: "idle"
at toBe (/opt/buildkite-agent/
```
Closes https://github.com/elastic/kibana/issues/1547
Closes https://github.com/elastic/kibana/issues/190342
Closes https://github.com/elastic/kibana/issues/197716
## Summary
This PR adds the ability for collapsible sections to be created and
managed on Dashboards.
https://github.com/user-attachments/assets/c5c046d0-58f1-45e1-88b3-33421f3ec002
> [!NOTE]
> Most of the work for developing collapsible sections occurred in PRs
contained to the `kbn-grid-layout` package (see [this meta
issue](https://github.com/elastic/kibana/issues/190342) to track this
work) - this PR simply makes them available on Dashboards by adding them
as a widget that can be added through the "Add panel" menu. As a result
of this, most work is contained in the Dashboard plugin - changes made
to the `kbn-grid-layout` package only include adding IDs for additional
tests that were added for the Dashboard integration.
### Technical Details
#### Content Management Schema
The content management schema allows for panels and sections to be mixed
within the single `panels` key for a dashboard **without** worrying
about section IDs; for example:
```
{
"panels": [
{
// this is a simplified panel
"gridData": {
"x": 0,
"y": 0,
"w": 12,
"h": 8,
},
"panelConfig": { ... },
},
{
// this is a section
"gridData": {
"y": 9,
},
"collapsed": false,
"title": "Section title",
"panels": [
{
// this is a simplified panel
"gridData": {
"x": 0,
"y": 0,
"w": 24,
"h": 16,
},
"panelConfig": { ... },
},
],
},
]
}
```
#### Saved Object Schema
The dashboard saved object schema, on the other hand, separates out
sections and panels under different keys - this is because, while we are
stuck with panels being stored as `panelJSON`, I didn't want to add much
to this. So, under grid data for each panel, they have an optional
`sectionId` which then links to a section in the `sections` array in the
saved object:
```
{
"panelsJSON": "<...> \"gridData\":{\"i\":\"panelId\",\"y\":0,\"x\":0,\"w\":12,\"h\":8,\"sectionId\":\"someSectionId\"} <...>"
"sections": [
{
"collapsed": false,
"title": "Section title",
"gridData": {
"i": "someSectionId",
"y": 8.
}
}
],
}
```
This allows sections to be serialized **without** being stringified.
This storage also matches how we store this data in runtime using
`layout`.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [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
- [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)
## Release note
Adds collapsible sections to Dashboard, which allow panels to grouped
into sections that will not load their contents when their assigned
section is collapsed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Previously, we weren't considering an assignment with a single field
name to be a "complete" expression in `EVAL`. This changes that because
it seems like people are using `EVAL` for this, even though we also have
a `RENAME` command.
https://github.com/user-attachments/assets/eab58527-ebfa-45bc-abb1-63b996ebbeac
## Summary
Change are in support of Endpoint space awareness and most of them are
to Fleet services which are used from within the Security Solution
plugin.
### Fleet Changes
- Several modules were updated with `.debug()` statements in order to
better debug issues and understand code flow.
- Some modules where updated to ensure that calls to SO Client methods
handle errors better (using a new Error utility named
`catchAndWrapError`)
- `PackagePolicy` and `AgentPolicy` services `.get()` methods where
updated to internally call `getById()` in order to support retrieving
policies with an un-scoped SO clients (allows for use of `namespaces:
[]` when using SoClient.bulkGet()`)
### Security Solution Changes:
- Manifest Manager was updated to
- ensure it retrieves policies across all spaces
- Ensure a properly scoped SO client is used when making updates -
including ensuring that when calling bulk update type of methods, the
updates are first grouped by space ID and then each group is called with
an SO client scoped to that space.
- Fleet server extension point callbacks were updated to ensure an
un-scoped SO client is used when they are invoked, so that policies can
be found in any space
- Policy Watcher and Policy Telemetry Watcher (background tasks) were
updated to ensure they retrieve policies across all spaces and if
needing ot update policies, that is done using a properly scoped
SoCLient.
- Several `.debug()` statements were sprinkled through out in order to
better understand code flow and failures that are logged to the kibana
log
## Summary
Fixes#178571
This PR reverts #221248 adding the missing part on it to make the bug
found in #178571 disappear.
In fact there was just a single line missing who was meant to keep the
suggestion frame version up to date with the latest workspace state.
I've tried to add a unit test but it was so hard to actually follow the
code underneath, so I settled to add a FTR, which led to few more
extras:
* subtype selector now has test ids
* Lens page now has few more utility helpers for layer cloning and sub
type selector
### 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
### Gemini connector: makes `maxOutputTokens` an optional, configurable request parameter
This PR updates the Gemini connector to make the `maxOutputTokens` request parameter, which was previously included in all requests with a (non configurable) value of `8192`, an optional, configurable request parameter.
- `maxOutputTokens` is no longer included in requests to Gemini models by default
- It may be optionally included in requests by passing the new `maxOutputTokens` parameter to the Gemini connector's `invokeAI` and `invokeAIRaw`, and `invokeStream` APIs
The driver for this change was some requests to newer models, e.g. Gemini Pro 2.5 were failing, because previously all requests from the Gemini Connector were sent with the value `8192` [here](f3115c6746/x-pack/platform/plugins/shared/stack_connectors/server/connector_types/gemini/gemini.ts (L397)).
The previous, non-configurable limit was less than the output token limit of newer Gemini models, as illustrated by the following table:
| Model | Description |
|--------------------|------------------------------------|
| Gemini 1.5 Flash | 1 (inclusive) to 8193 (exclusive) |
| Gemini 1.5 Pro | 1 (inclusive) to 8193 (exclusive) |
| Gemini 1.5 Pro 002 | 1 (inclusive) to 32769 (exclusive) |
| Gemini 2.5 Pro | 1 (inclusive) to 65536 (exclusive) |
When newer Gemini models generated a response with more than `8192` output tokens, the API response from Gemini would:
- Not contain the generated output, (because the `maxOutputTokens` limit was reached)
- Include a finish reason of `MAX_TOKENS`,
- Fail response validation in the connector, because the `usageMetadata` response metadata was missing the required `candidatesTokenCount` property, per the _Details_ below.
#### Details
Attack discovery requests to Gemini 2.5 Pro were failing with errors like the following:
```
ActionsClientLlm: action result status is error: an error occurred while running the action - Response validation failed (Error: [usageMetadata.candidatesTokenCount]: expected value of type [number] but got [undefined])
```
A full example error trace appears in the _Details_ below (click to expand):
<details>
```
ActionsClientLlm: action result status is error: an error occurred while running the action - Response validation failed (Error: [usageMetadata.candidatesTokenCount]: expected value of type [number] but got [undefined])
Response validation failed (Error: [usageMetadata.candidatesTokenCount]: expected value of type [number] but got [undefined]): ActionsClientLlm: action result status is error: an error occurred while running the action - Response validation failed (Error: [usageMetadata.candidatesTokenCount]: expected value of type [number] but got [undefined])
at ActionsClientLlm._call (/Users/$USER/git/kibana/x-pack/platform/packages/shared/kbn-langchain/server/language_models/llm.ts:112:21)
at async ActionsClientLlm._generate (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:375:29)
at async ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:176:26)
at async ActionsClientLlm.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:34:24)
at async RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1291:27)
at async RunnableCallable.generate [as func] (/Users/$USER/git/kibana/x-pack/solutions/security/plugins/elastic_assistant/server/lib/attack_discovery/graphs/default_attack_discovery_graph/nodes/generate/index.ts:61:27)
at async RunnableCallable.invoke (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/utils.cjs:82:27)
at async RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1285:33)
at async _runWithRetry (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/retry.cjs:70:22)
at async PregelRunner._executeTasksWithRetry (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/runner.cjs:211:33)
at async PregelRunner.tick (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/runner.cjs:48:40)
at async CompiledStateGraph._runLoop (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/index.cjs:1018:17)
at async createAndRunLoop (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/index.cjs:907:17)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:176:37)
at ActionsClientLlm._generate (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:374:20)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:176:37)
at async ActionsClientLlm.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:34:24)
at async RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1291:27)
at async RunnableCallable.generate [as func] (/Users/$USER/git/kibana/x-pack/solutions/security/plugins/elastic_assistant/server/lib/attack_discovery/graphs/default_attack_discovery_graph/nodes/generate/index.ts:61:27)
at async RunnableCallable.invoke (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/utils.cjs:82:27)
at async RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1285:33)
at async _runWithRetry (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/retry.cjs:70:22)
at async PregelRunner._executeTasksWithRetry (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/runner.cjs:211:33)
at async PregelRunner.tick (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/runner.cjs:48:40)
at async CompiledStateGraph._runLoop (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/index.cjs:1018:17)
at async createAndRunLoop (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/index.cjs:907:17)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:142:51)
at CallbackManager.handleLLMStart (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/callbacks/manager.cjs:464:25)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:142:51)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:136:73)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:136:73)
at ActionsClientLlm._generateUncached (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:129:28)
at ActionsClientLlm.generate (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:281:25)
at ActionsClientLlm.generatePrompt (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:97:21)
at ActionsClientLlm.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/language_models/llms.cjs:34:35)
at RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1291:43)
at async RunnableCallable.generate [as func] (/Users/$USER/git/kibana/x-pack/solutions/security/plugins/elastic_assistant/server/lib/attack_discovery/graphs/default_attack_discovery_graph/nodes/generate/index.ts:61:27)
at async RunnableCallable.invoke (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/utils.cjs:82:27)
at async RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1285:33)
at async _runWithRetry (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/retry.cjs:70:22)
at async PregelRunner._executeTasksWithRetry (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/runner.cjs:211:33)
at async PregelRunner.tick (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/runner.cjs:48:40)
at async CompiledStateGraph._runLoop (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/index.cjs:1018:17)
at async createAndRunLoop (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/pregel/index.cjs:907:17)
at RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1285:70)
at raceWithSignal (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/utils/signal.cjs:4:30)
at RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1285:70)
at async RunnableCallable.generate [as func] (/Users/$USER/git/kibana/x-pack/solutions/security/plugins/elastic_assistant/server/lib/attack_discovery/graphs/default_attack_discovery_graph/nodes/generate/index.ts:61:27)
at async RunnableCallable.invoke (/Users/$USER/git/kibana/node_modules/@langchain/langgraph/dist/utils.cjs:82:27)
at async RunnableSequence.invoke (/Users/$USER/git/kibana/node_modules/@langchain/core/dist/runnables/base.cjs:1285:33)
```
</details>
The root cause of the validation error above was models like Gemini 2.5 Pro were generating responses with output tokens that reached the `maxOutputTokens` limit sent in the request.
When this happens, the response from the model:
- Includes a `finishReason` of `MAX_TOKENS`
- The `usageMetadata` does NOT include the `candidatesTokenCount`, which causes the validation error to occur
as illustrated by the following (partial) response:
```json
{
"candidates": [
{
"content": {
"role": "model",
"parts": [
{
"text": ""
}
]
},
"finishReason": "MAX_TOKENS",
// ...
}
],
"usageMetadata": {
"promptTokenCount": 82088,
"totalTokenCount": 90280,
"trafficType": "ON_DEMAND",
"promptTokensDetails": [
{
"modality": "TEXT",
"tokenCount": 82088
}
],
"thoughtsTokenCount": 8192
},
"modelVersion": "gemini-2.5-pro-preview-03-25",
"createTime": "2025-05-06T18:05:44.475008Z",
"responseId": "eE8aaID_HJXj-O4PifyReA"
}
```
To resolve this issue, the `maxOutputTokens` request parameter is only sent when it is specified via the Gemini connector's `invokeAI` and `invokeAIRaw` APIs.
#### Alternatives considered
All of the Gemini models tested will fail with errors like the following example when their (model-specific) output token limits are reached:
```
Status code: 400. Message: API Error: INVALID_ARGUMENT: Unable to submit request because it has a maxOutputTokens value of 4096000 but the supported range is from 1 (inclusive) to 65536 (exclusive). Update the value and try again.: ActionsClientLlm: action result status is error: an error occurred while running the action - Status code: 400. Message: API Error: INVALID_ARGUMENT: Unable to submit request because it has a maxOutputTokens value of 4096000 but the supported range is from 1 (inclusive) to 65536 (exclusive). Update the value and try again.
```
For example, passing a `maxOutputTokens` value of `32768` will work OK for `Gemini 1.5 Pro 002` and `Gemini 2.5 Pro`, but fail for `Gemini 1.5 Flash` and `Gemini 1.5 Pro`:
| Model | Description |
|--------------------|------------------------------------|
| Gemini 1.5 Flash | 1 (inclusive) to 8193 (exclusive) |
| Gemini 1.5 Pro | 1 (inclusive) to 8193 (exclusive) |
| Gemini 1.5 Pro 002 | 1 (inclusive) to 32769 (exclusive) |
| Gemini 2.5 Pro | 1 (inclusive) to 65536 (exclusive) |
As an alternative to removing `maxOutputTokens` from requests, we could have made it a required parameter to the `invokeAI`, `invokeAIRaw`, and `invokeStream` APIs, but that would require callers of these APIs to know the correct model-specific value to provide.
#### Desk testing
This PR was desk tested:
- Interactively in Attack discovery with the following models:
| Model |
|--------------------|
| Gemini 1.5 Flash |
| Gemini 1.5 Pro |
| Gemini 1.5 Pro 002 |
| Gemini 2.5 Pro |
- Interactively in Attack discovery with non-Gemini models, e.g. a subset of the GPT and Claude family of models (to test for unintended side effects)
- Via evaluations using `Eval AD: All Scenarios` for the Gemini connectors above, (and with the Claude / OpenAI models for regression testing)
- Interactively via the security assistant, to answer requests in tool calling, and non-tool calling scenarios
**Related Epic:** https://github.com/elastic/kibana/issues/179907
## Summary
This PR refactors prebuilt rules integration tests structure to streamline the implementation of test plans targeted [Prebuilt Rules Customization Milestone 4](https://github.com/elastic/kibana/issues/179907).
## Details
Existing integration tests structure have prebuilt rules related integration tests scattered around rules management area. Due to historical reasons and pace of the prebuilt rules customization development some old tests were updated, some new were added as random spots as well as some new tests structure was suggested.
This PR moves files and some tests around to the following structure
- `test_suites/detection_response/rules_management/prebuilt_rules` is the root folder for prebuilt rules related integration tests
- `customization_disabled` subfolder contains prebuilt rules integration tests covering scenarios when users have **insufficient** for customization license level (basic/essentials)
- `customization_enabled` subfolder contains prebuilt rules integration tests covering scenarios when users have **sufficient** for customization license level
- `customization_disabled` and `customization_enabled` subfoldera have test suites grouped by sub domains
- `prebuilt_rules_package` - contains integration tests related to detection rules Fleet package installation and updating, bootstrap is also belong to here
- `install_prebuilt_rules` - contains tests related to prebuilt rules installation from prebuilt rule assets
- `upgrade_prebuilt_rules` - contains tests related to prebuilt rules upgrade workflow
- `customization` - contains tests related to prebuilt rules customization including `is_customized` calculation
- `import_export` - contains tests related to exporting and importing customized and non-customized prebuilt rules
- `status` - contain status endpoints related tests
Closes https://github.com/elastic/kibana/issues/220278
## Summary
- implemented the change to hide `Observables` in the O11y UI. The
**features** property in the cases context provider now supports an
`observables : { enabled: boolean }` configuration, with the default set
to true. For Observability the `enabled` value will be passed as
`false`, and the observables feature will be rendered based on this.
---------
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
## Summary
Part of https://github.com/elastic/kibana/issues/215092
## Considerations
### `RRF` may change in the future
@ioanatia has stated that the command may change in the future as it's
not fully implemented yet.
### Licence check
Will be addressed at https://github.com/elastic/kibana/issues/216791https://github.com/user-attachments/assets/759470a2-4afa-4d20-adbf-cb3001895e95
## New command support checklist
### AST support
- [x] Make sure that the new command is in the local Kibana grammar
definition. The ANTLR lexer and parser files are updated every Monday
from the source definition of the language at Elasticsearch (via a
manually merged, automatically generated
[PR](https://github.com/elastic/kibana/pull/213006)).
- [x] Create a factory for generating the new node. The new node should
satisfy the `ESQLCommand<Name>` interface. If the syntax of your command
cannot be decomposed only in parameters, you can hold extra information
by extending the `ESQLCommand` interface. I.E., check the Rerank
command.
- [x] While ANTLR is parsing the text query, we create our own AST by
using `onExit` listeners at
`kbn-esql-ast/src/parser/esql_ast_builder_listener.ts`. Implement the
`onExit<COMMAND_NAME>` method based on the interface autogenerated by
ANTLR and push the new node into the AST.
- [x] Create unit tests checking that the correct AST nodes are
generated when parsing your command.
- [x] Add a dedicated [visitor
callback](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-esql-ast/src/visitor/README.md)
for the new command.
- [x] Verify that the `Walker` API can visit the new node.
- [x] Verify that the `Synth` API can construct the new node.
### Validating that the command works well when prettifying the query
- [x] Validate that the prettifier works correctly.
- [ ] Adjust the basic pretty printer and the wrapping pretty printer if
needed.
- [x] Add unit tests validating that the queries are correctly formatted
(even if no adjustment has been done).
### Creating the command definition
- [x] Add the definition of the new command at
`kbn-esql-validation-autocomplete/src/definitions/commands.ts`.
### Adding the corresponding client-side validations
- [x] Add a custom validation if needed.
- [x] Add tests checking the behavior of the validation following this
[guide](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-esql-validation-autocomplete/README.md#the-new-way).
### Adding the autocomplete suggestions
- [x] Add the suggestions to be shown when **positioned at** the new
command.
- [x] Create a new folder at
`kbn-esql-validation-autocomplete/src/autocomplete/commands` for your
command.
- [x] Export a `suggest` function that should return an array of
suggestions and set it up into the command definition.
- [ ] Optionally, we must filter or incorporate fields suggestions after
a command is executed, this is supported by adding the
`fieldsSuggestionsAfter` method to the command definition. Read this
documentation to understand how it works.
- [x] If the new command must be suggested only in particular
situations, modify the corresponding suggestions to make it possible.
- [x] Add tests following this
[guide](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-esql-validation-autocomplete/README.md#automated-testing).
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[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
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Drew Tate <drewctate@gmail.com>
Fixes https://github.com/elastic/kibana/issues/209789
## Summary
For `inputs` type integrations
([docs](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/dev_docs/input_packages.md)),
we install all the assets when creating the integration policy and not
at integration install time (like for "regular": integrations).
However the clean up of assets doesn't happen when removing the
integration policy and this leaves around orphaned assets that are not
working anymore.
- This PR adds a new endpoint that removes the datastream assets
```
DELETE kbn:/api/fleet/epm/packages/{pkgName}/{pkgVersion}/datastream_assets?packagePolicyId={Id}
```
- The new endpoint is called by the UI when removing the integration
policy;
- Only the datastream assets that match exactly the dataset name are
removed; assets that are common across the integration are kept and can
only be deleted when the whole integration is uninstalled.
Additional changes:
- I did some light refactoring of the functions for inputs-type
integrations to make the code more readable
- Updated the dev_docs about input-type integrations that haven't been
touched for long time
### Testing
- Install an input-type package, for instance "custom logs"
- Check the assets created under the tab `assets`
- Check that the package has only this integration policy
- Remove the integration policy for the package - a warning is shown:
<img width="937" alt="Screenshot 2025-05-09 at 16 58 51"
src="https://github.com/user-attachments/assets/0f86ab38-e0a9-47f5-91f5-71b83e17f2e3"
/>
- Verify that the assets related to the package are cleaned up as well
- Try again but with several integration policies
- In this case the clean up doesn't happen
### Delete assets when there are two integration policies with different
dataset names
Dataset names are`udp.generic` and `udp.test` - in the video I deleted
policy `udp-2` having dataset name `udp.test` and the relative assets
are no longer present:
https://github.com/user-attachments/assets/23350051-1b26-4e52-914d-62f784809c80
### Delete assets when there are two integration policies with same
dataset names
In this case there are two different policies having the same dataset
name `udp.generic`, when deleting the policy there is no warning to
remove the assets. In fact they can be deleted only when there is only
one remaining policy using them:
https://github.com/user-attachments/assets/f75668dd-a4ce-4f5a-ba5d-c99911278dfc
### Checklist
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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: jillguyonnet <jill.guyonnet@gmail.com>
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 | `68e0781` ->
`464821c` |
---
### 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>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `3d19648` ->
`9ccddc0` |
---
### 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
Attempt to fix flakyness of the embeddable alerts panel functional test
by decreasing the interval of the rules that are used to generate alerts
to 5 seconds and parallelizing the execution of async tasks that are not
dependent on one another.
Not backporting to the 8.x track on purpose since the original PR
introducing this functional test hasn't been backported yet because of
this issue (will include the same fix in the backport branch).
## Summary
With https://github.com/elastic/kibana/pull/207036 we introduced some
changes in the script so that it generates two PRs: one for the `main`
branch and one for `8.x` in order to keep previous versions with their
corresponding console definitions.
This PR updates the branches so the script generates PRs for `main`,
`9.0`, `8.19` and `8.18`
## Summary 🌹Resolves#213024.
The frontend changes for
[#216377](https://github.com/elastic/kibana/pull/216377).
Depends on #216377 and https://github.com/elastic/kibana/pull/216292.
## Testing these changes 🌸
This adds frontend integration with the API changes we previously merged
in #216377. There is a new editor in the Rule Create/Edit Detail view,
below the pre-existing field for naming the rule.
To test that this feature is working you should:
- This is easiest to test if you have actual data that will trigger an
alert in your cluster. If you need some fake data, you can use the nifty
`data-forge` utility with a command like:
```shell
node x-pack/scripts/data_forge.js --events-per-cycle 200 --lookback now-1h --ephemeral-project-ids 10 --dataset fake_stack --install-kibana-assets --kibana-url http://localhost:5601 --event-template bad
```
- Create a rule with an investigation guide specified. This is easy.
Write some Markdown text into the editor and save the rule. My favorite
rule for testing the feature is Custom Threshold, because it's easy to
configure an alert that will fire. But this works for any rule.
<img width="1260" alt="image"
src="https://github.com/user-attachments/assets/bf9bf866-2439-456a-a700-1a93ae2e5dac"
/>
- After you create your rule, it should fire at some point, ideally.
Using the Observability -> Alerts view, drill into the Alert Details
page. There, you should find a spiffy new tab called _Investigation
Guide_. Confirm the contents on that tab are your markdown, properly
rendered.
<img width="1000" alt="image"
src="https://github.com/user-attachments/assets/bff19e48-da44-4886-bcf7-a296559c0aca"
/>
- Repeat step 1-2 as many times as you like with different rule types,
if you desire.
- Edit your rule, using the edit page or flyout.
<img width="606" alt="image"
src="https://github.com/user-attachments/assets/1a6149fe-016a-4b8c-9846-24cb2931aed3"
/>
- When you save the rule you should be able to refresh the alert details
page and see the modified Investigation Guide reflected in the tab.
---------
Co-authored-by: Panagiota Mitsopoulou <giota85@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
