8.17 PR - https://github.com/elastic/kibana/pull/215474
Part of https://github.com/elastic/security-team/issues/12176
Unskiped:
### `use_list_artifact.test.tsx`
Path
`.../plugins/security_solution/public/management/hooks/artifacts/use_list_artifact.test.tsx`
Closes https://github.com/elastic/kibana/issues/196724
Commit 438553a1d1
Reason for unskipping: Couldn't recreate failure locally. Increased
timeout from 1000 to 5000 ms.
### `actions_log_users_filter.test.tsx`
Path
`.../plugins/security_solution/public/management/components/endpoint_response_actions_list/components/actions_log_users_filter.test.tsx`
Closes https://github.com/elastic/kibana/issues/193554https://github.com/elastic/kibana/issues/193092
Commit ca7b971683de03fd5448fb3910e738
Reason for unskipping: wrapped expects in waitFor since they are
awaiting for state change. Increased the delay between keystrokes when
typing. Increased the timeout of tests since locally they are bordering
5s executions.
### `bad_argument.test.tsx`
Path
`.../plugins/security_solution/public/management/components/console/components/bad_argument.test.tsx`
Closes https://github.com/elastic/kibana/issues/193093
Commit 6959cd2e3f
Reason for unskipping: wrapped expects in waitFor since they are
awaiting for state change. Increased timeout to 10s.
### `use_get_endpoint_details.test.ts`
Path
`.../plugins/security_solution/public/management/hooks/endpoint/use_get_endpoint_details.test.ts`
Closes https://github.com/elastic/kibana/issues/192435
Commit 3ba10029b6
Reason for unskipping: increased timeout of waitFor for
renderReactQueryHook to 5s since locally it was bordering 3 seconds
## Summary
Closes https://github.com/elastic/kibana/issues/214355
Testing with Chrome 135.x.x.x resulted in a pop up that was breaking the
flow of tests:
<img width="470" alt="Screenshot 2025-03-20 at 4 25 17 PM"
src="https://github.com/user-attachments/assets/df908294-1881-4b6d-b9a2-3027b37b06ad"
/>
This isn't captured by the screenshotting plugin, but is visible if you
run `headless=0`
This adds the config to disable that popup since our generic testing
passwords are very common and therefor flagged
## Summary
This PR removes the declarative objects that were meant to describe the
behavior of "options" (see details section below if you don't know what
I'm talking about). **It does not remove "options" as a concept from our
AST.** "Option" is probably the wrong name for the subcommands in the
AST but, at the moment, it is working fine how it is.
Here is a list of what these definitions were being used for and where I
ended up.
| Use | How it worked | What I did |
|---------------------------------------------------------------------|---------------|------------|
| To generate command declarations for display in suggestions menu | It
had some complex logic to try to construct a declaration string from the
information in the `signature` property | I replaced this with
statically declared declaration strings on the command definitions. I
took most of them directly from our docs. They are a better result than
the autogenerated stuff |
| To build the `METADATA` suggestion | the definition was passed into
`buildOptionDefinition` | I declared the `METADATA` suggestion
statically in the `FROM` autocomplete code. |
| To check for field correctness in `METADATA` | This logic lived in the
option definition's `validate` method | I moved it to the `FROM`
command's validate method |
| To validate the type of the value assigned to `APPEND_SEPARATOR` in
`DISSECT` | This logic lived in the option definition's `validate`
method | I moved it to the `DISSECT` command's validate method |
| To check if the left side of the equals sign in `DISSECT` is
"APPEND_SEPARATOR | In most cases, the parser catches stuff like this,
but for some reason `DISSECT`'s grammar is very loose so we have been
stepping in with our own validation (maybe we should suggest changing
this). This was the only case that was triggering the "Unknown option"
message. | I moved it to the `DISSECT` command's validate method |
| To prevent default column validation for `METADATA` | This was the
only true use of the `skipCommonValidation` property which would prevent
the validator trying to find metadata fields in the standard field list
| I inserted an option name check directly into the validation code.
It's not a good long-term solution, but it is actually an improvement
since the former code pretended to be general but was actually just for
`METADATA`. At least now it is clear what the exception is for. |
| To filter functions and operators that are available after `BY` |
Function definitions sometimes declare that they are supported in a `by`
statement. The validator checks if the function does. | This didn't
change. The option nodes in the AST are still there and we are still
relying on the `supportedCommands` and `supportedOptions` properties in
the function definitions. |
#### Pictures
<img width="859" alt="Screenshot 2025-03-20 at 1 47 36 PM"
src="https://github.com/user-attachments/assets/3bd3c3c6-6066-466e-b33b-9444ab58670a"
/>
_New, statically-defined declarations_
<img width="783" alt="Screenshot 2025-03-20 at 2 12 28 PM"
src="https://github.com/user-attachments/assets/94550b25-5da9-4c82-9586-11b3515debd7"
/>
_In cases besides `APPEND_SEPARATOR`, incorrect keywords produce syntax
errors._
<img width="700" alt="Screenshot 2025-03-20 at 2 09 05 PM"
src="https://github.com/user-attachments/assets/de1a23f4-2509-4c6e-84ec-a807e96b65a5"
/>
_Didn't break the `APPEND_SEPARATOR` datatype validation_
<img width="791" alt="Screenshot 2025-03-20 at 2 03 28 PM"
src="https://github.com/user-attachments/assets/169aaa15-52f3-4d22-ab77-26a560cd9359"
/>
_Didn't break `METADATA` fields validation_
### 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
### Background/details
Till now, "options" have been a concept in our code. Their definition
isn't clear, but it essentially comes down to any capitalized keyword
after the command name. For example `STATS... >BY<`, `DISSECT...
>APPEND_SEPARATOR<`. You could think of them as roughly subcommands or
substatements.
There was a hope that commands would be uniform enough that these
"options" would deserve to be their own special first-class citizen. But
they break conceptually...
For example `APPEND_SEPARATOR` is not a keyword with an expression after
it... it is a variable `APPEND_SEPARATOR=":"`... or filtering in
stats.... `STATS AVG(bytes) >WHERE<` .... so is WHERE an option now?
`FORK` will break this even further.
So, we are moving the architecture to allow for complexity and variance
among the commands. Command-specific logic will have the final say in
how autocomplete and validation work for anything with that command.
## Summary
Closes https://github.com/elastic/kibana/issues/210298
In this PR we are adding the initial structure for the
@kibana/scout-security package, note that this is not ready to be used
and any new test using this package, is not going to be executed as part
of the regular pipelines, meaning, you are not going to add coverage to
the application.
@kibana/scout-security package is a test package that extends @kbn/scout
with test helpers specifically designed to test Security Solution
functionalities in Kibana. All tests under Security plugins should only
import from @kbn/scout-security, not from @kbn/scout.
This PR is a POC to start testing development by providing custom
Playwright fixtures, page objects, and utilities tailored for
Security-related testing scenarios.
Things to follow-up:
- CustomQueryRule interface is already declared in
`x-pack/solutions/security/plugins/security_solution/common/api/detection_engine/model/rule_schema/rule_schemas.gen.ts`
as `QueryRuleCreateProps`
- DETECTION_ENGINE_RULES_URL and DETECTION_ENGINE_RULES_BULK_ACTION are
already declared in `@kbn/security-solution-plugin/common/constants`
It would be great if all of that is extracted from the plugin to a
package so it can be reused instead of having to duplicate the code.
Until the package is not ready to be used and has not been introduced to
the different teams, appex-qa and myself will be the owners of it to
make sure that best practices are followed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Creates a wrapper plugin around the alerts table, that registers a basic
alerts table embeddable panel for dashboards.
> [!NOTE]
> This PR is a preparation work for the [embeddable alerts
table](https://github.com/elastic/kibana/issues/197483). The feature is
disabled for end-users while waiting for other dependent PRs to be
integrated with this, and uses a partially hard-coded table
configuration for testing purposes. The final panel will be fully
configurable by the user.
## Verification steps
1. Uncomment this line
4d49e98b4d/x-pack/platform/plugins/shared/embeddable_alerts_table/public/plugin.ts (L34)
(I'm using a comment to avoid polluting the embeddable examples app with
this panel for a short time)
2. Create one or more ES Query rules that fire alerts
3. Visit the Dashboards page and create a dashboard, then enter edit
mode
4. Click "Add panel"
5. Under "Visualizations" choose "Alerts table"
6. Check that the table panel was created correctly
6.1. Shows any alerts fired by the ES Query rule(s)
6.2. Check that the table adapts correctly to the panel when resizing,
and all normal interactions with the alerts table work correctly
(adding/removing fields, opening alerts in flyouts, using row/bulk
actions)
6.3. Check that panels respond to the global time filter (only time
filters, not KQL search or filters)
6.4. Check that panels respond to individual time filters (⛭ icon >
Apply custom time range)
11. Create a role with access to dashboards but without any alerting
capability and a user assigned to that role
12. Repeat steps 3 and 4, and verify that the "Alerts table" option
isn't available under "Visualizations"
13. Add any alerting capability to the role, such as Management > Stack
rules
14. Repeat steps 3 and 4, and verify that the "Alerts table" is
available again
## References
Closes#203611
### 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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The PR updates the implementation to fetch data from the Risk Engine
Saved Object instead of storing and reusing it from LocalStorage.
This change ensures that settings are applied globally rather than being
limited to the browser’s LocalStorage. Since the Saved Object holds the
most up-to-date information, it is now used to update the "Date" and the
toggle for "including closed alerts for risk scoring" across all web
browsers.
### Normal and Incognito Mode :
https://github.com/user-attachments/assets/7638c88b-ff9e-4d42-9944-e55b53e33518
### Default space vs custom space :
https://github.com/user-attachments/assets/46bb35c7-3cd9-4b97-9f1c-90ec4ef1241a
## Testing Steps
### Verify Initial Values
1. Open the Entity Risk Score web page where the settings are applied.
2. Ensure that the date picker and toggle for "including closed alerts"
reflect the values stored in the Risk Engine Saved Object rather than
LocalStorage.
3. Modify and Save changes,
- Change the date range in the date picker.
- Toggle the "Include Closed Alerts" switch.
### Page Refresh Test
- Refresh the page and confirm that the modified values persist, fetched
correctly from the Risk Engine Saved Object.
### Cross-Browser Test
- Open the same web page in a different browser or incognito mode.
- Verify that the settings are consistent and correctly loaded from the
Risk Engine Saved
Object.
### Expected Outcome
The settings should persist after a page refresh or across different
browsers.
The latest values should always be pulled from the Risk Engine Saved
Object.
### 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
- [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)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| @​openfeature/launchdarkly-client-provider | dependencies |
patch | [`^0.3.1` ->
`^0.3.2`](https://renovatebot.com/diffs/npm/@openfeature%2flaunchdarkly-client-provider/0.3.1/0.3.2)
|
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNvcmUiLCJUZWFtOlNlY3VyaXR5IiwiYmFja3BvcnQ6cHJldi1taW5vciIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Provides the Cases service to the detection engine alerts table. The
missing services caused the cases actions to disappear from the bulk
actions menu.
## Verification steps
1. Create Security rules that fire alerts
2. Visit the Security > Alerts page
3. Select one or more alert rows from the table
4. Open the `Selected X alerts` bulk action menu
5. Check that the cases bulk actions are available
## Release Notes
Fixes a regression that caused the cases actions to disappear from the
detections engine alerts table bulk actions menu.
### 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] 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)
This PR overhauls the overview page.
Classic stream:
<img width="1004" alt="Screenshot 2025-03-12 at 21 00 39"
src="https://github.com/user-attachments/assets/a058da08-0ae2-48cc-abca-359b23288b32"
/>
Wired stream:
<img width="1019" alt="Screenshot 2025-03-12 at 21 01 56"
src="https://github.com/user-attachments/assets/bca04537-f79b-4814-8e31-9d3dae18ad90"
/>
## Doubts / things I changed from the design
* Quick links is just all dashboards, so I adjusted the wording
accordingly. Also, since we render all dashboards, there isn't really
value in "View all assets"
* The panel on top is already stating the count of docs, why should we
repeat that in the histogram panel?
* No search bar - in the beginning we said we don't want this page to
become discover, a search bar feels like we are going there. Also, what
should the user enter there? I don't think we want to buy deeper in KQL
* Should the count of docs be the total count of the count for the
currently selected time range? Not sure what makes more sense
* For wired streams I left the tabs in place to switch between child
streams and quick links. We can revisit this once we get closer to
actually releasing wired streams
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/212905
## Summary
This PR adds autocompletion for data-stream related endpoints.
Previously, it didn't work because the generated spec definitions that
were extracted from the Es specs repo were using the generic `{name}`
pattern instead of `{data_stream}`. In this PR, we override those
definition files and specify the correct pattern.
### How to test:
Test the following endpoints and make sure that data stream names are
suggested:
`GET _data_stream/{data_stream}/_stats`
`DELETE _data_stream/{data_stream}/_lifecycle`
`DELETE _data_stream/{data_stream}`
`GET _data_stream/{dataStream}/_lifecycle`
`GET _data_stream/{data_stream}`
`POST _data_stream/_migrate/{data_stream}`
`POST _data_stream/_promote/{data_stream}`
`PUT _data_stream/{data_stream}/_lifecycle`
## Summary
This PR establishes the foundation for executing API tests in the new
`search_ai_lake` tier, following the existing API integration test
structure and guidelines.
## Adding a New Test
To add a new test, follow these guidelines:
- Inside the `AI4DSOC` folder, create subfolders representing different
AI4DSOC functionalities.
- Each subfolder should be owned by an area team or the developers
actively working on it.
- The functionality folder must include a `search_ai_lake_tier`
subfolder.
- The `search_ai_lake_tier` subfolder should contain a `configs`
directory with a `serverless.config.ts` file that imports
`createTestConfig` from `config.base.ai4dsoc`.
- Add the test inside the `search_ai_lake_tier` subfolder.
- Ensure the test has the `@serverless` label and uses
`supertestWithoutAuth` instead of `supertest`, as `supertest` provides
basic authentication, whereas serverless environments require API key
authentication. See the `dummy_test.ts` for reference.
- The `search_ai_lake_tier` folder should have an `index.ts` file
referencing the tests to be executed, as demonstrated in this PR.
- Update the
`x-pack/test/security_solution_api_integration/package.json` file with
the necessary scripts to enable test execution locally.
- When adding a new `serverless.config.ts` file, ensure it is included
in `.buildkite/ftr_security_serverless_configs.yml`. Otherwise, the new
test(s) will not be executed as part of the PR process.
## Running Tests Locally
Execute the tests using the following Yarn scripts from
`x-pack/test/security_solution_api_integration`:
1. Start the server with the required configuration:
```sh
yarn ai4dsoc_cases:server:serverless
```
2. Run the tests using the started server:
```sh
yarn ai4dsoc_cases🏃serverless
```
## Key Considerations
- `Supertest` should not be used, as it provides basic authentication.
Instead, use supertestWithoutAuth for API key authentication.
- All tests must include the `@serverless` label.
- MKI is not yet supported for test execution.
- Temporary Ownership: The Security Engineering Productivity team will
initially own the AI4DSOC testing folder to ensure proper structure and
best practices. Once teams are familiar with the workflow, this
ownership will be removed.
## Security Engineering Productivity Code Ownership Responsibilities
The Security Engineering Productivity team should ensure:
- All tests are placed inside a functionality-specific subfolder.
- Each functionality subfolder has designated code owners.
- Tests include the `@serverless` label.
- `Supertest` is not used.
- The correct configuration is applied.
- Scripts are added to enable local execution.
- New configurations are added to
`.buildkite/ftr_security_serverless_configs.yml`.
## Follow-Up tasks
- Remove the existing dummy test.
- Integrate tests into the periodic pipeline.
- Add tests to the Kibana QA quality gate.
## Summary
This PR is the setting the foundations for the AI for SOC Alert summary
page. It has very little UI, instead it focuses on the following:
- add routing for the `alert_summary` page
- fetches the integrations, filters them to only keep the ones related
to AI for SOC, then decides what to render depending on if some AI for
SOC packages have been installed or not
The PR also makes a small change to the `SecurityRoutePageWrapper`
component, to allow us to redirect to the Security Solution HomePage
instead of the NoPrivilegesPage. While this might not be a long term
solution, it is the easiest path forward. In the future, AI for SOC will
most likely be its own plugin (leaving outside of Security Solution)
hence this will not be needed anymore.
Here's the basic behavior of the Alert summary page:
- The `Landing page` will be shown if none of the hardcoded AI for SOC
packages are installed (these values are hardcoded as we currently do
not have a way to filter integrations for the AI for SOC ones only):
- splunk // doesnt yet exist
- google_secops
- microsoft_sentinel
- sentinel_one
- crowdstrike
- The `Wrapper` component will only be shown if you have at least one of
the above AI for SOC packages installed.
### Very limited UI added in this PR
| Loading integrations | No installed packages | Some installed packages
|
| ------------- | ------------- | ------------- |
| 
| 
| 
|
### Notes
We need to remove the section at the top of the page that currently
shows the `Add integrations` button. A follow PR will take care of that.
[This](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/app/home/index.tsx#L54)
is where that bar is being added. We will have to find a way to not show
that for the AI for SOC tier.
## 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' },
]
```
The Alert summary navigation will NOT be shown for the following
Serverless users: `viewer`, `t1_analyst`.
and `t2_analyst`. For those, the navigation entry is not present, and
navigating to the url directly will automatically re-route to the
Security home page.
Currently, retrieving the integrations (via the `fleet/epm/packages`
endpoint) is also unauthorized for the following users: `editor`,
`t3_analyst`, `threat_intelligence_analyst`, `rule_author`,
`soc_manager` and `detections_admin`.
This means that the only users that can be currently used to test this
PR are:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### 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
Will help close https://github.com/elastic/security-team/issues/11954 as
well as https://github.com/elastic/security-team/issues/11979.
## Summary
Some of the text in the Synthetics README is 6+ years old, which is
older than Synthetics itself. We need to try to keep these instructions
up to date a bit more as they are intended to be useful to inexperienced
contributors.
## Summary
- Adds support for double param: (1) `??` unnamed; (2) `??name` named;
and (3) `??123` positional.
- In the `@kbn/esql-ast` package.
- Adds types, parsing, builder and pretty-printing support.
### 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
Closes https://github.com/elastic/kibana/issues/208001
## Summary
- Added filtering option in the `create connector` flyout:
- Search field:
- search connectors by name (or description)
- cards dynamically update based on the input
- includes a clear button to reset the search
Demo:
https://github.com/user-attachments/assets/6d38a916-ad05-41dd-867e-c37260913067
---------
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes#215106
This PR removes `service.environment` as a required field for
`getTopDependencySpans` endpoint.
It was not used at all, so it can be safely removed without adapting the
UI.
## Summary
When the data view refresh API or task was executed, it was overwriting
the engine's additional `indexPattern`.
This PR updates the code to support `indexPattern` and ensures the user
has privileges for all indices.
I extracted the merge function to add deduplicate logic.
### How to reproduce it?
* Create an entity store using the indexPatterns param
* Call refresh dataview API (`POST
kbn:api/entity_store/engines/apply_dataview_indices`)
* It will apply the dataview and ignore the indexPatterns param
After the fix, we should be able to update the indexPatterns param, and
the task that refreshes the index pattern should pick up the change
properly.
### 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
## 📓 Summary
Part of https://github.com/elastic/streams-program/issues/38
This work adds the `date` processor along with the dissect and grok ones
in the enrichment section.
It scales well following the current folder structure, but we should
definitely polish it a bit more once more processors get added, such as
getting the right form component, improve form state derivation, etc.
https://github.com/user-attachments/assets/824d15c8-ce9d-455a-ae0b-97aeec8cf025
---------
Co-authored-by: Kerry Gallagher <kerry.gallagher@elastic.co>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kerry Gallagher <471693+Kerry350@users.noreply.github.com>
- Closes https://github.com/elastic/kibana/issues/214554
## Summary
This PR:
- adds TabPreview component, which is visible when you hover over a
particular tab
- adds tests for TabPreview component
About TabPreview component
- EUI doesn't have a component, which would suit for our needs, hence a
custom component activated on hover
- TabPreview should activate (with 500ms of delay) after hovering over a
whole tab
- It should hide when we click action button in the tab or we open
editing name mode
- It shouldn't appear on hover when we have tab context menu open or
we're editing a title
- For now the data inside is mocked (besides of title), so you can see
random queries and statuses each time you hover over the tab
- Preview should not overflow the screen if there are a lot of tabs and
they're "touching" right side of the screen
https://github.com/user-attachments/assets/da0a47dd-b594-4c20-b76c-49e6889f3814
## Testing
Two options are possible:
1. start Storybook with `yarn storybook unified_tabs` and navigate to
`http://localhost:9001`.
2. start Kibana with `yarn start --run-examples`. Then navigate to the
Unified Tabs example plugin
`http://localhost:5601/app/unifiedTabsExamples`.
### 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: Julia Rechkunova <julia.rechkunova@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Currently Kibana forwards `query_range_secs` and `query_offset_secs` to
mark the selected time range when reporting TTFMP event. This format
caused some challenges to identify `from`, `to` date offsets in
visualizations.
To simplify, the PR renames and sends the three fields explicitly:
- `query_from_offset_secs` offset to `0` (now), with -ve for past and
+ve for future dates
- `query_to_offset_secs` offset to `0` (now), with -ve for past and +ve
for future dates
- `query_range_secs` same as previously sent
_This approach is followed after a discussion, and based on the
[gist](https://gist.github.com/andrewvc/1f04a57a336d768e4ec5ff2eff06ba54)
excerpt:_
```
Earliest date -> QueryFrom
Newest date -> QueryTo
Duration -> QueryRange
```
### Indexing
These fields then should be mapped in the EBT indexer to ingest in the
top level of the document, eventually removing the need to create
runtime fields in data views for visualizations.
Also, runtime fields in data views should be updated to reflect this
change. For backward compatibility, the runtime fields can cater both
the old and new field names conditionally.
### Testing
- Ensure that the TTFMP events are correctly reporting the date ranges.
### Example
