## Summary
https://github.com/user-attachments/assets/6b174348-5138-48a3-9a52-103831913bde
This hacks push flyout to push content
To not touch EUI for now, I listen to style changes that EUI sets on
body, then set them to css variable and use them to push content by push
flyout
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
DefaultPresentationPanelApi should define parentApi as unknown.
`ReactEmbeddableRenderer` renders panels with `PresentationPanel`.
`PresentationPanel` takes `api: DefaultPresentationPanelApi` as a prop
and `DefaultPresentationPanelApi` should not define ParentApi type more
precisely then its defined in `ReactEmbeddableRenderer`.
`ReactEmbeddableRenderer` defines parent as `ParentApi extends
HasSerializedChildState<SerializedState> =
HasSerializedChildState<SerializedState>`.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR introduces space awareness to internal Defend Insights APIs.
While these endpoints are not exposed through the UI, they can still be
queried via Dev Tools. The goal is to prevent users from accessing
insights or related data tied to agents outside of their current space.
In the `security_solution` plugin, space validation is added to:
- `GET /internal/api/endpoint/workflow_insights`
- `PUT /internal/api/endpoint/workflow_insights/{insightId}`
In the `elastic_assistant` plugin, similar validation is enforced via
service-level callbacks:
- `POST /internal/elastic_assistant/defend_insights`
- `GET /internal/elastic_assistant/defend_insights`
- `GET /internal/elastic_assistant/defend_insights/{id}`
These use `onBeforeCreate` and `onAfterFetch` hooks to enforce space
checks during insight creation and retrieval.
The validation works by collecting all agent IDs involved in the request
- whether provided directly or pulled via search queries - and verifying
that each one belongs to the current space. This is done using the Fleet
service, which throws if any of the agents are not found in the space.
If all agents are valid, the request continues; otherwise, an error is
returned.
Closes#214557
### Summary
Use `traceId` to generate url link to Span as fallback when
`transactionId` is missing.
### How to test
1. Run the following synthtrace scenario: `node scripts/synthtrace
span_links.ts --live --uniqueIds --clean --logLevel=debug --scenarioOpts
pipeline=apmToOtel`
2. Go to **Service** -> **Transactions** -> in **Transaction waterfall**
click **Span Links** label -> select **Outgoing links** from downdown ->
check if **Span** link works
https://github.com/user-attachments/assets/c22fdc5e-7ba9-4817-a78b-bf5fb9a53651
---------
Co-authored-by: jennypavlova <dzheni.pavlova@elastic.co>
## Summary
Bootstrap Privileged User Monitoring page. This page is hidden behind
`privilegeMonitoringEnabled` flag.
### Included
* Add the Privileged User Monitoring page content according to design
* Link integrations to the integrations page
* Find index modal
* New API to search for compatible indices
* It also renames the navigation title to only have the first letter
capitalised.
### Not Included
* The navigation is already implemented by
https://github.com/elastic/kibana/pull/217180
* The video introduction
* The final API call in the "choose index" is out of scope for this
issue.
* The CSV upload functionality is entirely out of scope for this ticket.
* The "Sample Dashboard"
* The link to docs
### How to test it?
* Enable `privilegeMonitoringEnabled` flag.
* Start kibana.
* Use the menu to navigate to the Priv User monitoring page
### 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] [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Partially addresses #210531.
This doesn't fully fix the ticket linked, as elements that control the
annotation look in the second half of the form still trigger re-renders.
This means the focus will still be lost when those elements are
modified.
This is going to require significant refactoring of this form, but this
patch will at least make the elements reachable via tabbing.
The custom `onBlur` removed here doesn't seem to impact the form and the
rendering issues are prominent in any case.
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
Closes: #218128
**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 required aria-attributes for mentioned places
## Summary
Part of #213045
This PR fixes an issue when the `observability:entityCentricExperience`
flag is enabled.
By some reason, we may get null values in `sourceDataStreams` and when
we try to validate it with the zod schema, it breaks.
Closes: #215689
**Description:**
When user clicks on add panel and then selects any of the observability
embeddable panels (SLO burn rate, SLO Overview, SLO Alerts, SLO Error
budget, Monitors overview, Monitors stats), Kibana announces them as
"you are in a modal dialog. Press escape or tap click outside the
dialog....This doesn't give non-sighted user context about the add panel
action they are trying to execute.
**Changes Made:**
1. Added `aria-labelledby={flyoutTitleId}` for mentioned places
## Summary
Change usage of Handlebars.compile across Kibana to use
`@kbn/handlebars` and `compileAST`
### Note for reviewers:
There should be no change for the rendered output where it's used.
Wherever there were tests, i ensured they were passing after making the
change.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Allows one to export and import content packs in archive format. The
format follows the integration content package's format so it becomes
possible to import existing integration packages.
Content packs only support dashboard assets at the moment.
A pattern replacement logic has been implemented for dashboards and
referenced data views:
- at export time, any pattern matching the source stream will be
replaced with a placeholder. Other patterns will remain as-is unless
user explicitly ask to replace them
- at import time, the placeholders are replaced with the target stream
pattern
For example, if a dashboard is first exported from stream `logs.nodejs`
and reads data from patterns `logs.nodejs` and `logs.nodejs.prod`, the
patterns will be updated to `logs.ruby` and `logs.ruby.prod` when
imported into `logs.ruby` stream.
The relevant UI components are hidden behind a feature flag, set the
following in `kibana.dev.yml` to enable them:
`feature_flags.overrides.featureFlagsStreams.contentPackUIEnabled: true`
https://github.com/user-attachments/assets/9fb07daf-9fb9-4c62-9f5b-387e1833eaf0
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: tommyers-elastic <106530686+tommyers-elastic@users.noreply.github.com>
## Summary
Fixed the navigation tests for es3 to close the console tour, in
addition I abstracted the side nav test cases to be more uniform and
wait for a specific test object on the page before moving to the next
side nav link.
I tested these against MKI
Closes#218719
### 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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
## Summary
While testing, we realized that the Cases alerts tab was showing the
`DetectionEngineAlertsTable` and the normal alert details flyout, even
in the AI4DSOC tier. This PR updates the logic to show the correct
alerts table and the correct alert details flyout depending on the tier:
- AI4DSOC will show the same table and flyout as the ones shown in the
Alert summary page
- the other tiers will continue showing the same table and flyout we
show today under the Alerts page or any other pages
(`DetectionEngineAlertsTable`)
Switching the table allows us to tackle at once all the other related
issues:
- wrong flyout was being shown
- too many row actions were being shown
- wrong default columns, and wrong cell renderers
### Notes
The approach is not ideal. We shouldn't have to check for the following
```typescript
const AIForSOC = capabilities[SECURITY_FEATURE_ID].configurations;
```
in the code, but because of time constraints, this was the best
approach.
[A ticket](https://github.com/elastic/kibana/issues/218741) has been
opened to make sure we come back to this and implement the check the
correct way later.
Current (wrong) behavior
https://github.com/user-attachments/assets/5d769f45-26d9-4631-af95-de38b0797ff9
New behavior
https://github.com/user-attachments/assets/1f9a2e4d-50b7-40e6-8efa-1a0cfdbf5c9a
## How to test
This needs to be ran in Serverless:
- `yarn es serverless --projectType security`
- `yarn serverless-security --no-base-path`
You also need to enable the AI for SOC tier, by adding the following to
your `serverless.security.dev.yaml` file:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
### 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
Relates to https://github.com/elastic/security-team/issues/11973
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
While testing, we realized that the Attack Discovery alerts tab was
showingn the `DetectionEngineAlertsTable`, even in the AI4DSOC tier.
This PR updates the logic to show the correct alerts table depending on
the tier:
- AI4DSOC will show the same table as the Alert summary page
- the other tiers will continue showing the same table as the Alerts
page (`DetectionEngineAlertsTable`)
Switching the table allows us to tackle at once all the other related
issues:
- wrong flyout was being shown
- too many actions were being shown
- wrong default columns, and wrong cell renderes
### Notes
The approach is not ideal. We shouldn't have to check for the following
```typescript
const AIForSOC = capabilities[SECURITY_FEATURE_ID].configurations;
```
in the code, but because of time constraints, this was the best
approach.
[A ticket](https://github.com/elastic/kibana/issues/218731) has been
opened to make sure we come back to this and implement the check the
correct way later.
Current (wrong) behavior
https://github.com/user-attachments/assets/c41a25f1-ae9a-4bbf-9c02-9b1054f3a0e3
New behavior
https://github.com/user-attachments/assets/0eb20a2f-ba00-42c0-9353-7ac788c9bea0
### 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
Relates to https://github.com/elastic/security-team/issues/11973
addresses #217294
This PR migrates all existing enzyme usage to react-testing-library.
This PR is not attempting to refactor or move from unit testing to
integration style testing with less mocks. In fact I add even more mocks
in some places where after moving out of enzyme things start to blow up
because enzyme structure was hiding the lack of mocks.
Here is essence of the change:
- all shallow toMatchSnapshot tests have been migrated to render()
toMatchSnapshot() tests which has caused an expected spike in amount of
changes. For now I am leaving it as is. Later we can decide on what to
do (either selective mock underlying implementations to shrink snapshot
sizes or cut them altogether in favor of specific element existence
assertions
- some dead tests were cut that were passing with enzyme. Enzyme is
testing the component tree not the dom tree giving a false sense of
stuff being rendered when it's not, that's why we have to cut it out.
- in some places I use `expect(container.children[0]).toMatchSnapshot()`
as a viable alternative for not introducing an unnecessary
`data-test-subj` locator on the root element. The result is the same.
- wherever possible I replaced selectors usage in tests to
`screen.getByTestId` and where not to `container.querySelector` or
`document.querySelector`(for global selection)
- other matchers were transitioned as is
### Fix: Bedrock Streaming Error on ES|QL Actions
#### Summary
When an ES|QL is generated, we present two action buttons:
- Visualize Query
- Display Results
These actions were not working as expected when using Bedrock as the
model provider.
#### Error Details
```txt
Encountered error in Bedrock stream of type validationException messages.8: Did not find 1 `tool_result` block(s) at the beginning of this message. Messages following `tool_use` blocks must begin with a matching number of `tool_result` blocks.
```
#### Root Cause
We were sending a tool_use block in the assistant message without
immediately following it with the corresponding tool_result block. This
violates Bedrock’s message protocol.
## Summary
This PR only renames the helper, no test implementations were changed.
Why now?
Migrating tests from Enzyme to RTL means that all usage of
`mountWithIntl` has to change and will likely be replaced by the helper
that wraps RTL render with I18n. [A shorter name improves devEx](url).
ATM, consumption is limited to a few tests, reducing the number of
codeowner reviews required.
### Identify risks
- [x] In progress work and open PRs might fail. Updating from main will
prompt an undefined function that will need to be renamed.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
