## Summary
This PR is probably the final PR that makes the changes to support EUI
Borealis. It focuses on removing all the usage of EUI Json tokens.
You will notice different approaches while removing the tokens:
- for some cases, the changes were done using `css from
'@emotions/react'` as the components using the tokens were already using
`euiTheme` or adding it was straightforward and required the minimal
amount of changes
- for some cases, where the css changes were pretty involved, a hook was
created to be able to import the styles and apply them in the components
- finally for other cases, esepcially if the styled components were
extracted in a different file and were used within many others, I
decided to create reusable components. This allowed to not change all
the files impacted and limit the number of files modified in this PR.
Feel free to comment on any of the approaches and suggest better
options!
https://github.com/elastic/kibana/issues/201889
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Starting in 9.1-SNAPSHOT, the Elastic Agent image has moved from the
`beats` namespace to its own `elastic-agent` namespace in
docker.elastic.co. This PR updates a few places where the old path is in
use.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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.
- [ ] This was done with a generic find/replace across the Kibana
codebase. I did not test the changes extensively and made a few changes
outside of the Fleet codebase. Codeowners please be aware.
## Summary
Closes https://github.com/elastic/kibana/issues/201710.
Implements filters section for Asset Inventory reusing `FilterGroup`
component from `@kbn/alerts-ui-shared` package.
### Screenshot
<img width="1740" alt="Screenshot 2025-01-17 at 16 21 55"
src="https://github.com/user-attachments/assets/bf83d9e8-4919-498d-a0ab-fdc3df711d4e"
/>
### Definition of done
- [x] Add multiple dropdown filters labelled:
- Type - filter by `asset.category`
- Criticality - filter by `asset.criticality`
- Tags - filter by `asset.tags.name`
- Name - filter TBD
- [x] Ensure each dropdown allows users to select multiple options to
filter the inventory data.
- [x] Add a button or dropdown labeled "More filters" that exposes
advanced filtering options, including "Reset control" and "Edit
control".
- [x] Verify if the `FilterGroup` component from
`packages/kbn-alerts-ui-shared` can be reused to wrap the required
functionalities.
- It can be reused, but the detection engine uses `AlertFilterControls`
instead, which is a higher-level alternative. And that's what I did in
Asset Inventory too
- [x] Ensure the filters are functional on the front-end and can
interact with placeholder data.
### Out of scope
- Backend data filtering logic
- Implementation of the actual data fetching based on filters
### How to test
Follow the "how to test" instructions written on this PR:
- https://github.com/elastic/kibana/pull/206115
### Checklist
- [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] 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)
### Risks
No risks at all.
## Summary
This PR includes the following updates:
- Converted `readOnly` fields to `disabled` to ensure consistency across
all view-only fields.
- Added an `isPreconfigured` check to disable the `num_allocations`
field. While `num_allocations` is the only updatable field for
`Elasticsearch` services, it cannot be modified if the endpoint is
preconfigured.
### Not preconfigured
### Preconfigured
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
Closes#210610
This PR removes `error.id` field from being queried at
`getErrorGroupMainStatistics`, as it was not being used, as it was
required. If we didn't have this field, the endpoint call would crash.
## Summary
`@kbn/scout-oblt` is a test library that extends `@kbn/scout` with test
helpers specifically designed to test `Observability` applications in
Kibana. All Oblt plugins should only import from `@kbn/scout-oblt`
Its primary goal is to simplify the test development experience for
teams working on `Observability` plugins by providing custom Playwright
fixtures, page objects, and utilities tailored for Observability-related
testing scenarios.
Contributing:
- when Fixture/Page Object is sharable across all Solutions and Platform
(`fleetApi` fixture), it should be added in `@kbn/scout`
- when Fixture/Page Object is Oblt-specific but is shared across tests
under the multiple plugins (`OnboardingHome` page), it should be added
in `@kbn/scout-oblt`
- when Fixture/Page Object is only used in a single plugin (`onboarding`
internal APIs ?), it should be added in this plugin.
I also re-worked existing tests with few ideas in mind:
- Scout is **e2e testing tool** and should target primary e2e test
scenarios; We have _API integration tests_ to test multiple short
scenarios for APIs behavior (response, status code) and _jest/React
testing library_ to test components in isolation (elements rendering,
fields validation). Doing all the testing with e2e tool like Playwright
will dramatically affect cost efficiency and stability of tests, but
also slows overall CI execution and PRs delivery. The goal is to follow
testing pyramid and keep in mind its principles.
- We on purpose spin up new browser context for each `test` block to
make sure our **tests are independent**. Having too many short `test`
blocks in the file significantly slows down the execution: every block
triggers browser context, saml authentication, adding/removing Fleet
integrations (each call up to 2 seconds) and other beforeEach/afterEach
hooks. Real browser-based testing is expensive. It is not about putting
every step into 1 `test` block, but also not a Jest unit-test-style
design. When it is possible to group similar actions on the same page
and if it is a part of the same user flow - we should do it. It also
doesn't bring the testing value repeating the same UI steps multiple
times in different scenarios. _Our CI costs are critical to cut when it
is possible_
- Avoid **nesting describe** blocks: it complicates test readability and
also complicates for CI bot to properly skip the failing block (it will
skip the top level one). We encourage **Scout parallel test execution**
based on running test spec files in multiple workers, not the `test`
blocks within the same file. Having too many `test` blocks in the same
file will be slowly run in the single thread and in case of flakiness,
it means Team lose more test coverage than they probably expect.
Before (**59** test blocks - **8-8.5 min** per distro):
<img width="1709" alt="Screenshot 2025-02-08 at 18 01 40"
src="https://github.com/user-attachments/assets/5fd65a1c-85f9-4594-9dae-3f8e99a005ab"
/>
After (**15** test blocks - **3.5-4 min** per distro):
<img width="1578" alt="Screenshot 2025-02-10 at 18 14 42"
src="https://github.com/user-attachments/assets/6846898f-7dd2-4f6b-8bc5-d06741b0b120"
/>
For reviewers: updated tests are possible to run in 2 parallel workers
against the same Kibana/ES instance and run time is dropping to **2.5-3
min** 🚀 . It is up to UX-Logs team to decide if you want to keep
parallel run (new tests can be added either to parallel or sequential
run)
<img width="1578" alt="Screenshot 2025-02-11 at 12 14 30"
src="https://github.com/user-attachments/assets/e94113f2-d7f1-470e-a6d5-cb5154d99c41"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adding an additional check to see if the selected model has been
deployed before continuing with the upload.
The `num_allocations` count can occasionally be incorrect, so this also
checks to see if the initial call to the inference api has returned with
no error. If it has, the model must be deployed.
To test:
Manually deploy both `.elser_model_2` and `.multilingual-e5-small` in
ML's trained models page.
In dev tools call:
```
POST /_inference/.multilingual-e5-small-elasticsearch
{
"input": ""
}
```
then call:
```
POST /_inference/.elser-2-elasticsearch
{
"input": ""
}
```
Once both models have been deployed, check the `num_allocations` of
`.elser-2-elasticsearch`
```
GET /_inference/.elser-2-elasticsearch
```
It should be `0` even though the model has been deployed.
If it isn't `0`. wait around 15mins for both models to scale down then
repeat the dev tools commands.
Call this to check `num_allocations ` in both models.
```
GET /_inference/_all
```
**Resolves: https://github.com/elastic/kibana/issues/208357**
**Resolves: https://github.com/elastic/kibana/issues/208355**
## Summary
To prevent possible OOM errors, we need to limit concurrent requests to
prebuilt rule routes (see attached tickets for more details).
- `installation/_perform` and `upgrade/_perform` endpoints
- Concurrency is limited to one parallel call. If another call is made
simultaneously, the server responds with 429 Too Many Requests.
- On the front end, all rule install and upgrade operations are retried
in case of a 429 response. This ensures proper handling when a user
clicks multiple times an update or install rule buttons
- `prebuilt_rules/_bootstrap` endpoint
- Install prebuilt rules and endpoint packages sequentially instead of
in parallel to prevent from having them both downloaded into memory
simultaneously.
- Added a 30-minute socket timeout to prevent the proxy from closing the
connection while rule installation is in progress.
- Introduced a `throttleRequests` wrapper, ensuring the endpoint handler
is called only once when multiple concurrent requests are received.
- The first request triggers the handler, while subsequent requests wait
for the first one to complete and reuse its result.
- This prevents costly prebuilt rule package installation from running
in parallel.
- Reusing the response ensures the frontend correctly invalidates cached
prebuilt rule queries. Since concurrent frontend requests should receive
the same installed package information, responding with 421 and using
the retry logic as in cases above is not an option here because the
second request would receive a package installation skipped response
leading to no cache invalidation.
- `installation/_review` and `upgrade/_review` endpoints
- Concurrency is limited to one parallel call. If another call is made
simultaneously, the server responds with 429 Too Many Requests.
- On the front end, all rule install and upgrade operations are retried
in case of a 429 response. This ensures proper handling when a user
clicks multiple times an update or install rule buttons
## Summary
Fixes#208924
This PR improves the numeric check for the Last value agg within the
Metric chart type avoiding completely to access the active data and
rather rely on the datasource configuration.
The new utility function in fact won't rely any more on active data
rather on the Lens configuration itself, which is more robust, faster
and flexible.
<img width="2552" alt="Screenshot 2025-01-31 at 14 30 12"
src="https://github.com/user-attachments/assets/5f8792db-40ff-497b-8e2f-0737c2932f92"
/>
### Notes for testing
I've created a testing dashboard with all the possible combinations of
colouring for metric and tables.
[last_value_dashboard.ndjson.txt](https://github.com/user-attachments/files/18618905/last_value_dashboard.ndjson.txt)
### 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
## Release note
This fixes an issue where dynamic colouring has been disabled from Last
value aggregation types.
## Summary
This PR migrates the last routes with `access:<privilege>` tags used in
route definitions to new security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before Migration:**
Access control tags were defined in the `options` object of the route:
```ts
router.get({
path: '/api/path',
options: {
tags: ['access:<privilege_1>', 'access:<privilege_2>'],
},
...
}, handler);
```
### **After Migration:**
Tags have been replaced with the more robust
`security.authz.requiredPrivileges` field under `security`:
```ts
router.get({
path: '/api/path',
security: {
authz: {
requiredPrivileges: ['<privilege_1>', '<privilege_2>'],
},
},
...
}, handler);
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
closes [#210427](https://github.com/elastic/kibana/issues/210427)
## Summary
This PR adds component tests for the processes list and summary.
## Fixes
It also fixes a DOM validation warning I saw once I ran the test
(visible also in the browser):
<img width="1423" alt="Dom validation warning"
src="https://github.com/user-attachments/assets/9eac7d9c-369d-4cd0-97c0-c616cf6eaa3c"
/>
## Testing
- Run:
- `node scripts/jest
x-pack/solutions/observability/plugins/infra/public/components/asset_details/tabs/processes/processes_table.test.tsx`
- `node scripts/jest
x-pack/solutions/observability/plugins/infra/public/components/asset_details/tabs/processes/summary_table.test.tsx`
## Summary
This PR resolves a minor bug in one of the telemetry events, it also
adds a try/catch around the event reporting to prevent it crashing on
failures.
I also moved our reportEvent wrapper function to use generics so that we
get proper typehint/checks on the events to prevent issues similar in
the future.
Revert the change in https://github.com/elastic/kibana/issues/198172.
It re-enables version constraints for packages in 9.0 by default,
following the plan described in internal issue
https://github.com/elastic/ingest-dev/issues/4484.
We already have some packages ready for 9.0, and many more coming, so it
should be enough for testing purposes during the FF.
Adjust some tests config so they continue disabling the constraints, as they
expect more packages than the ones available now.
## Summary
* Removes the download model button by extending the deploy action.
* The model download begins automatically after clicking Start
Deployment.
* It is possible to queue one deployment while the model is still
downloading.
* Navigating away from the Trained Models page will not interrupt the
downloading or deployment process.
* `State` column renamed to `Model State`
* Responsiveness fix: icons overlap
https://github.com/user-attachments/assets/045d6f1f-5c2b-4cb5-ad34-ff779add80e3
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This updates the Search notebooks config path to fix a config conflict,
now that the main search plugin owns `xpack.search`. This config should
only have been used in Serverless and was never pushed to other users,
but I've added a rename and deprecation warning just in case anyone used
it..
## Summary
During package installation, failure to update the default pipeline for
data streams currently has a misleading error message. This PR corrects
this and adds the original error message to improve clarity.
### Identify risks
N/A
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
While working on https://github.com/elastic/ingest-dev/issues/4722 I
identified an issue in `UnenrollInactiveAgentsTask` in the batch
processing of agent policies. As it is, the task ends if no inactive
agents were found for an agent policy batch, regardless of whether there
could be inactive agents assigned to policies in further batches. This
means that for stacks with over 500 agent policies, it could be possible
that some inactive agents never get unenrolled (or at least not
predictably, since that depends on the order in which the agent policy
fetcher returns them).
I added a unit test to test this and also fixed a couple of other unit
tests.
### 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
### Identify risks
Low probability of affecting automatic unenrolling of inactive agents on
stacks with over 500 agent policies.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/180057
The following items needed to be replaced with add panel actions
* vega - visType
* markdown - visType
* lens - visTypeAlias
* maps - visTypeAlias
As an added benefit, now these actions are displayed in embeddable
examples that uses ADD_PANEL_TRIGGER
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
