## Summary
This PR refactors naming and logic in EntityStoreEnablementModal to
improve readability and better distinguish between:
1. Feature enablement state – Whether Risk Score or Entity Store is
actually enabled.
2. User-selected state – Whether the user has checked the corresponding
toggle.
#### Changes
- Renamed disabled → canToggle to clearly represent UI interaction.
- Renamed enablements → userSelectedEnablements to reflect user-selected
toggle states, not feature enablement.
- Refactored shouldAllowEnablement logic for clarity and correctness:
- If riskScore is enabled, return whether the user has enabled
entityStore.
- If entityStore is enabled, return whether the user has enabled
riskScore.
- Otherwise, return true if either toggle is selected.
- Updated corresponding tests to reflect naming and logic changes.
## Testing/Validation
Manually tested the toggling behaviour still works as before and modal
still shows warning, and disables the "enable" button when there are no
available options selected.
### Validation Video
https://github.com/user-attachments/assets/0f2a3f59-e2a0-4c8b-a350-70a9573a8566
## Summary
BUG: https://github.com/elastic/security-team/issues/11783
This PR fixes the behaviour of the
`/api/security_ai_assistant/chat/complete` route where the `persist`
flag:
1. when set to `true` does not append the assistant reply to existing
conversation
2. when set to `false` appends user message to existing conversation
### Expected behaviour
[Details](https://github.com/elastic/security-team/issues/11783#issuecomment-2674565194).
1. `conversationId == undefined && persist == false`: no new
conversations and nothing persisted
2. `conversationId == undefined && persist == true`: new conversations
is created and both user message and assistant reply appended to the new
conversation
3. `conversationId == 'existing-id' && persist == false`: nothing
appended to the existing conversation
4. `conversationId == 'existing-id' && persist == true`: both user
message and assistant reply appended to the existing conversation
### Testing
* Use this `curl` command (with replace `connectorId` and
`conversationId`) to test the endpoint.
```
curl --location 'http://localhost:5601/api/security_ai_assistant/chat/complete' \
--header 'kbn-xsrf: true' \
--header 'Content-Type: application/json' \
--data '{
"connectorId": "{{my-gpt4o-ai}}",
"conversationId": "{{existing-conversation-id | undefined}}",
"isStream": false,
"messages": [
{
"content": "Follow up",
"role": "user"
}
],
"persist": true
}'
```
* To retrieve the conversation ID:
(/api/security_ai_assistant/current_user/conversations/_find)
* `conversationId` can be either existing conversation id or `undefined`
Adds a v2 version of the file upload api which spits away the upload
initialisation step from the data upload api.
Previously the import data API would behave differently depending on
whether an ID was passed to it. If an ID was not present, the api would
"initialize the upload" by creating the index, mappings and pipeline.
Subsequent calls to the api would the pass in an ID as well as the data.
The ID being present meant the data would be ingested.
The ID had not other purpose other than signifying whether this was the
initial call to create the index or the subsequent calls to ingest the
data.
This change adds a new `initialize_import` api which is called first to
create the index et al.
Subsequent calls to the `import` api behave as before and the data is
ingested.
A temporary v1 version of the `import` has been kept for backwards
compatibility during upgrades.
The `initialize_import` also creates multiple ingest pipelines by
default. Improving the previous "hacked in" addition of having two sets
of pipelines passed to it to provide backwards compatibility.
## Summary
As a part of Expandable Findings flyout, we will need to move some
Constants, Types, Functions, Components into Security Solution plugin or
Shared package
This PR is phase 1 for Findings (Misconfiguration flyout) which include
moving constants and types into shared package or security solution
plugin
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Epic:** https://github.com/elastic/kibana/issues/174168
**Partially addresses:**
https://github.com/elastic/kibana/issues/202068,
https://github.com/elastic/kibana/issues/202078,
https://github.com/elastic/kibana/issues/202079
**Follow-up to:** https://github.com/elastic/kibana/pull/211472
## Summary
We're cleaning up and refactoring our existing test plans for prebuilt
rule customization, upgrade, and export/import workflows.
Specifically, this PR:
- Updates the common structure of test plans:
- Adds a tip to each test plan's header to help with navigating all our
test plans for prebuilt rules.
- Introduces a new `Requirements` section to each one and consolidates
assumptions, technical requirements and product requirements under it.
- Each `Product requirements` section now contains relevant user stories
and other product details. In the document flow this is kept close to
the `Scenarios` section.
- Updates the test plan template according to the updated structure.
- Moves the documentation about customizable and non-customizable rule
fields to the common info document.
- Restores the lost changes from commit
bde4612e52.
No "functional" changes have been made to any test plans, such as
adding, removing, or updating any scenarios. The only functional-like
changes were made to the user stories when creating/updating the product
requirements sections.
This PR wraps up the refactoring efforts aimed to prepare the test plans
for being "functionally" changed and improved in follow-up PRs. In the
following PRs, we're going to cover the logic described in
https://github.com/elastic/kibana/issues/210358, address any gaps in the
coverage, and improve the scenarios structure and wording.
## Review tip
It might be easier to review this PR commit-by-commit as each of them
contains logically cohesive changes.
As a first step towards making parts of streams owned by different teams
working on it, this PR gives some of the things to the logs UX team.
These routes and views are clearly associated with the workstreams the
logs UX team moves forward. It's still expected that a lot of changes
(but probably not all) will have at least a portion outside of this code
area, but it's meant to put a starting point into place to make the
separation stronger over time.
For the API it's just about certain route handlers. For the UI, the
relevant components are pulled into a separate directory to encapsulate
them somewhat.
---------
Co-authored-by: Milton Hultgren <miltonhultgren@gmail.com>
Fixes#211439
## Summary
@simianhacker pointed out that the `alignEventsToInterval` setting
aligns the data generation so that we have the exact number of documents
in each bucket; I noticed this setting is missing for the burn rate rule
test.
### How to run the test
```
// Server
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
// Test
node scripts/functional_test_runner --config=x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="Burn rate rule"
```
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
## Summary
#### Changes in support of space awareness
> currently behind feature flag:
`endpointManagementSpaceAwarenessEnabled`
- Add logic to the server-side Lists plugin extension points for
endpoint artifacts to ensure that only a user with the new Global
Artifact Management privilege can update/change/add `ownerSpaceId` tags
on an artifact
- Added validation to all endpoint artifacts (Trusted Apps, Event
Filters, Blocklists, Host Isolation Exceptions and Endpoint Exceptions)
#### Other changes:
- Fix UI bug that failed to display artifact submit API failures. API
errors are now displayed in the artifact's respective edit/create forms
if encountered
- Fixed a bug where "unknown" artifact `tags` were being dropped
whenever the artifact assignment (global, per-policy) was updated in the
UI
## 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Update Preconfigured connector name to `Elastic LLM`.
<img width="1504" alt="Screenshot 2025-02-20 at 11 29 02 AM"
src="https://github.com/user-attachments/assets/aa0a32f7-f1b2-4496-8c2e-7773f017c153"
/>
### ES3 Testing instruction
No additional config needed. Once run in local machine, the changes
should reflect automatically.
### ESS instructions
In `kibana.dev.yml` file, add
```
# xpack.actions.preconfigured:
Elastic-LLM:
name: Elastic LLM
actionTypeId: .inference
exposeConfig: true
config:
provider: 'elastic'
taskType: 'chat_completion'
inferenceId: '.rainbow-sprinkles-elastic'
providerConfig:
model_id: 'rainbow-sprinkles'
```
and the preconfigured endpoint with updated name should be visible.
### 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
closes https://github.com/elastic/observability-dev/issues/4185
## Summary
This PR adds the `is_initial_load` parameter to the meta field to
distinguish whether the `onPageReady` trigger occurs during the initial
load or a page refresh.
Refactoring:
- Removed the `target` field. as `context.pageName` now provides the
necessary information
- Refactor APM instrumentation to simplify it
Fixes:
- https://github.com/elastic/observability-dev/issues/3464
### ⚠️ Instrumentation
The plugins need to call the following function:
``` onPageRefreshStart()```
This method adds a performance marker `start::pageRefresh` to indicate when a page refresh begins. This marker is used along with an end marker `end::pageReady` to determine the total refresh duration.
https://github.com/user-attachments/assets/62587d18-b33e-437b-9774-d8e196dbf764https://github.com/user-attachments/assets/e9c9a761-57bc-4743-9cc7-ea7634696ee3
### How to test
- Checkout the PR
- make sure you run `yarn kbn bootstrap`
- go to any page that has onPageReady function instrumented (ex services)
### TODO
- Once approved, update docs
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Resolves https://github.com/elastic/kibana/issues/211063
Adds a small manual test plan for the UX app.
The UX app is quite small and straightforward so the test plan is pretty
basic.
## Summary
Removes the citations feature flag added in this PR:
https://github.com/elastic/kibana/pull/206683
#### How to test:
- Add the feature flag to kibana.dev.yaml
`xpack.securitySolution.enableExperimental:
['contentReferencesEnabled']`
- Start Kibana
- You should see the log
```
The following configuration values are no longer supported and should be removed from the kibana configuration file:
xpack.securitySolution.enableExperimental:
- contentReferencesEnabled
```
- Remove the feature flag from kibana.dev.yaml
- Restart Kibana
- You should not see the log
- Open the Security AI assistant
- Check "Show citations" exists in the assistant settings menu
<img width="869" alt="image"
src="https://github.com/user-attachments/assets/34a4c812-bccd-4eef-a9f9-7c834faff951"
/>
- Ask the assistant a question about your knowledge base or an alert.
The response should contain a citation. (if it does not, append "include
citations" to your prompt)
- Use the shortcut option + c to toggle citations on and off. Observe if
this works as expected.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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]
[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
- [X] 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)
- [X] 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.
- [X] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [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)
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/ingest-dev/issues/4722
### Implementation checklist
- [x] Handle fetching agent policies and agents at scale
- [x] Only consider active agents for upgrade
- [x] Agents already on or upgrading to target version are included in
the count but not considered for upgrade
- [x] Agents stuck in updating are considered for upgrade
- [x] Bulk upgrade actions triggered by the task have an added
`isAutomatic:true` flag
- [x] Use rollout duration to spread bulk upgrade in time (1h or longer
depending on agent count)
### Testing
- This should be tested with real Elastic Agents (that will upgrade and
have `upgrade_details`).
- Edit the task interval in order to test how the task logic handles
agents already upgrading.
- Edit the agents batch size in order to test how the task logic handles
agents at scale.
- We should also check that space awareness is respected if enabled.
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [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)
### Identify risks
Risk of incorrectly triggering agent upgrades. Probability should be
very low if the agent policy does not have `required_versions` set.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updating the ES client to 9.0.
Resolves#116102
## What changes?
**Breaking change**: `body` has been removed.
Most of the changes are about bringing all the content inside the body
as a root attribute to the API params:
```diff
const response = await client.search({
index: 'test',
- body: {
query: {
match_all: {}
}
- }
})
```
For this reason, enabling the "Hide whitespace changes" option when
reviewing is recommended.
Some exceptions to this rule:
* Bulk APIs replace the `body` array with `operations` array (direct
replacement)
* Index Put Settings API replace `body` array with `settings` (direct
replacement)
* Msearch replaces the `body` array with `searches` array (direct
replacement)
* Document Index API replaces `body` with `document` (direct
replacement)
* Create Repository replaces `body` with `repository` (direct
replacement)
Because of a known issue in the client
(https://github.com/elastic/elasticsearch-js/issues/2584), there's still
an escape hatch to send data in the body in case the specific use case
requires it via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`, but it
shouldn't be abused because we lose types. In this PR we've used it in
those scenarios where we reuse the response of a GET as the body of a
PUT/POST.
### Other changes
* `estypes` can be imported from the root of the library as `import type
{ estypes } from '@elastic/elasticsearch';`
* `estypesWithBody` have been removed
* `requestTimeout`'s 30s default has been removed in the client. This PR
explicitly adds the setting in all client usages.
### Identify risks
- [x] The client places unknown properties as querystring, risking body
params leaking there, and causing 400 errors from ES => Solved by
forcing `body` usage there via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`. The next
version of the client will address this.
- [x] We need to run the MKI tests to make sure that we're not breaking
anything there =>
https://elastic.slack.com/archives/C04HT4P1YS3/p1739528112482629?thread_ts=1739480136.231439&cid=C04HT4P1YS3
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
Part of DW team effort -
https://github.com/elastic/security-team/issues/11804
This PR aligns the property/schema descriptions and examples in
AsciiDocs with OpenAPI schemas. The primary goal of this PR was not to
extend or enhance the documentation but to migrate from one system to
another.
Ascii docs -
https://www.elastic.co/guide/en/kibana/8.17/osquery-manager-api.html
OpenApi generated docs -
https://www.elastic.co/docs/api/doc/kibana/operation/operation-endpointgetactionslist
Changes:
Copied missing property descriptions from AsciiDoc to OpenApi properties
Copied existing AsciiDoc examples for both requests and responses
Fixed falsy query object in some GET requests - in OpenApi it was
defined as an object, not as path query params.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: natasha-moore-elastic <137783811+natasha-moore-elastic@users.noreply.github.com>
**Fixes: https://github.com/elastic/kibana/issues/206527**
**Partially addresses: https://github.com/elastic/kibana/issues/209518**
## Summary
Adds a normalization to the `filters` field in the rule diffing
calculation that omits all filter fields other than the `query` field
and the `negate` and `disabled` fields within the `meta` object. This
makes our diffing logic much more robust and resilient as we only
compare data in the rule fields that have an impact on the query itself
and not the fields that relate to UI implementation (`alias`, `key`,
etc).
### To test
- Open a prebuilt rule with `filters` in the non-customized rule
parameters (e.g. `PowerShell Script with Discovery Capabilities`)
- Edit the rule and save without editing
- The rule should remain unmodified even though more fields have been
added to the rule's `filters` field
Unless the user adds or deletes a filter on the rule, the rule should
only be marked as customized under 3 circumstances:
- The user negates the filter (adds NOT to the beginning of the filter)
- The user disables the filter
- The user changes the filter query
All other scenarios (such as adding a custom name for the filter) should
not change the rule's customized status
### 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
Closes#211910
## Summary
Currently, we validate that `inferenceClient.chatComplete` is called
twice (once for the title and once for the conversation) and that the
expected system message is included in each call. However, we do not
explicitly verify that the system message is actually passed to the LLM.
To improve reliability, we should introduce a test that directly
inspects the request sent to the LLM via `LLMProxy`.
### Solution - Add a test that explicitly inspects the request sent to
the LLM via `LLMProxy`. :
Forward the system message to the LLM'
Forward User Instructions via System Message to the LLM
sends the system message as the first message in the request to the LLM
## Summary
This PR changes the behavior of `indexing.alignEventsToInterval: true`
(`--align-events-to-interval`) to align the events to the nearest
interval instead of being based on when the command was called. This
change is to help increase the predictability of the documents. This
will also decrease the effects of the index latency on the events.
### Before
If the script was started at `2025-02-20T00:50:34.203Z` with `--interval
10000` then the events will be offset every `10` seconds from the start
time.
### After
If the script was started at `2025-02-20T00:50:34.203Z` with `--interval
10000` then the events will be offset from `2025-02-20T00:50:00.000Z`
every `10` seconds from the start time.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR fixes a incorrect UI test :
- Rules Upload File component should only display API Error in case it
occurs, while previously the tests was check if the button is disabled
or not. Disability of button is irrelevant.
### 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
Ensure Enable Button Considers Disabled State of Risk Score & Entity
Store. Previously only used the checked state of the toggle.
### Reproduce the Issue
Steps, as [per bug
ticket:](https://github.com/elastic/kibana/issues/209242#issue-2826951496)
1. Kibana version 8.16.0 or above should exist
2. Navigate to the Dashboards tab under Security
3. Select Entity Analytics dashboard
4. Click on the enable button and enable risk score
5. Disable the options for Entity store
6. Then again select the enable button for Entity store
7. Disable the enable button
8. Observe the Enable button is still enabled
### After Issue Solved
Same steps as above, but should show the warning and disable the button.
#### Videos
Videos show when either riskScore or entityStore is enabled, and the
other is unchecked, the warning should show and the button should be
disabled.
https://github.com/user-attachments/assets/236f9e69-f810-4116-9948-38fd27d4d945https://github.com/user-attachments/assets/2971e845-5d46-4eac-997a-79b3b17922c0
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
