Closes https://github.com/elastic/kibana/issues/172075
Closes https://github.com/elastic/kibana/issues/178396
## Summary
In order to move the links panel into general availability, this PR does
four main things:
1. It changes the default of the "Save to library" toggle in the flyout
from `true` to `false` - this is in response to some early telemetry,
which suggests that link panels **not** saved to the library are more
common.
| Before | After |
|--------|--------|
| 
| 
|
2. It fixes a styling issue in Serverless where the height of the
secondary edit/add link flyout was incorrect.
| Before | After |
|--------|--------|
|
|
|
3. It removes the lab setting for the links panel. The removal of this
setting is **not** a breaking change - it is completely safe to remove
this setting **regardless** of the previous value. Telemetry tracking
for this setting is also no longer required.
| Before | After |
|--------|--------|
| 
|
|
4. It removes any reference to "Technical preview" or "Experimental"
| Before | After |
|--------|--------|
| 
|
|
| 
| 
|
### 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] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Integrating latest translations extracted from main branch.
Skipping backports from main to target branches since the `i18n_check`
might trim unused translations that are still used in different
branches. Integration script is ran against each target branch
separately.
Towards: https://github.com/elastic/kibana/issues/169867
This PR onboards Log Threshold rule type with FAAD.
### To verify
Create a log threshold rule.
Example:
```
POST kbn:/api/alerting/rule
{
"params": {
"logView": {
"logViewId": "Default",
"type": "log-view-reference"
},
"timeSize": 5,
"timeUnit": "m",
"count": {
"value": -1,
"comparator": "more than"
},
"criteria": [
{
"field": "log.level",
"comparator": "equals",
"value": "error"
}
]
},
"consumer": "alerts",
"schedule": {
"interval": "1m"
},
"tags": [],
"name": "test",
"rule_type_id": "logs.alert.document.count",
"notify_when": "onActionGroupChange",
"actions": []
}
```
Your rule should create an alert and should saved it in
`.internal.alerts-observability.metrics.alerts-default-000001`
Example:
```
GET .internal.alerts-*/_search
```
Then set `count.value: 75`
The alert should be recovered and the AAD in the above index should be
updated `kibana.alert.status: recovered`.
## Summary
The current way we are using in our Cypress tests to saved queries, is
not working on MKI environments. This is because we are trying to modify
internal indexes directly, something that is completely forbidden in
real Serverless projects.
To solve the issue, we are using our APIs to perform the deletion
actions.
## Summary
In https://github.com/elastic/kibana/pull/170234, we added user input
validations in the settings fields. The validation functionality uses
the `schema` object from the settings definition. This PR adds more
detailed documentation of the `schema` property to make people more
aware of the validation functionality when registering a new setting.
## Summary
Part of:
- https://github.com/elastic/security-team/issues/8040
With the introduction of Agentless when a user enters smth in the JSON
credentials field in Agentless and then switches to Agent-based with the
Cloud Shell option selected by default, the JSON credentials value was
not reset. This was causing incorrect credentials data saved in the
policy.
This PR introduces the logic similar to what we already have for AWS and
Azure to make sure the default credentials types match the setup method
selected
GCP is different though in a way that the credentials type is a
combination of two vars: `setup_access` (values are `google_cloud_shell`
and `manual`) and `gcp.credentials.type` (values are `credentials-json`
and `credentials-file`) which is relevant only for `manual` setup
access. I introduce a new value `credentials-none` for
`gcp.credentials.type` which is set when `setup_access =
google_cloud_shell`. This allows to safely clean up credentials in the
fleet callback
If the call to `ObservabilityAIAssistantAppService.start` fails, show an
error toast to notify the user.
<img width="354" alt="Screenshot 2024-03-25 at 12 23 46"
src="021d442c-ec34-4acf-b441-6005acde1666">
## Summary
This PR adds heartbeat-like data for MongoDB in the `fake_stack` dataset
so users can express an SLO for that service. This also changes some of
the details in the Nginx data to allow for group-by on the same domain
names to be used in testing SLO alert dependencies.
## Summary
Address #169734 .
We're currently storing information about _Saved Object_ types in the
`<index>.mapping._meta`.
More specifically, we're storing hashes of the mappings of each type,
under the `migrationMappingPropertyHashes` property.
This allows us to detect which types' mappings have changed, in order to
_update and pick up_ changes only for those types.
**The problem is that `md5` cannot be used if we want to be FIPS
compliant.**
Thus, the idea is to stop using hashes to track changes in the SO
mappings.
Instead, we're going to use the same `modelVersions` introduced by ZDT:
Whenever mappings change for a given SO type, the corresponding
`modelVersion` will change too, so `modelVersions` can be used to
determine if mappings have changed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In this PR we are introducing several changes to make sure we have a
green execution of Cypress tests on MKI environments.
- Split `entity_analytics.cy.ts` between different spec files
- Skipped managed data section test on MKI
- Refactor of `installRiskScoreModule` method
#### Split `entity_analytics.cy.ts` between different spec files
The original spec file has a big execution time, what makes from time to
time in MKI environment to perform a log off.
To try to avoid that, we have splited the spec file in 3 new ones inside
the `entity_analytics` folder.
* anomalies.cy.ts
* legacy_risk_score.cy.ts
* new_risk_score.cy.ts
#### Skipped managed data section test on MKI
It has been skipped just on MKI (the test will be executed in PRs for
both serverless and ESS) since I don't know how to fix it. A
[ticket](https://github.com/elastic/kibana/issues/179248) has been
created to track it. It is now responsability of the team to investigate
what is happening (I can give support with that).
#### Refactor of `installRiskScoreModule` method
That method is returning a `401` on MKI, to fix it, we refactored to use
`rootRequest` instead since it uses the basic API authentication by
default.
## Summary
For ES|QL charts the formula api should be redundant. This is going to
make the api lighter as there is no need to import the lens plugin if
you want to use the builder to create ES|QL charts.
This PR moves the AI Assistant Management plugin into x-pack to
co-locate it with the other assistant plugins and to make it possible to
statically import from the other assistant plugins. This is not
currently possible because the Management plugin is in OSS and the other
plugins are in xpack.
## Summary
Allows rule executors to determine whether an alert is tracked from a
previous execution.
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
## Summary
This PR fixes the serverless reporting API integration tests for MKI
runs.
### The problem that we saw
After #178159 was merged, we saw the `Reporting Generate CSV` API
integration tests fail with `401` responses when running against MKI
projects. It turned out that the tests were using hard-coded credentials
that are only working locally / in CI - real serverless projects run
with a different set of username and password.
### How this PR fixes it
Remove hard-coded credentials from
`x-pack/test_serverless/shared/services/svl_reporting.ts` and instead
read them from the test config, which has the proper entries for local
and MKI runs.
I've also preemptively adjusted
`x-pack/test_serverless/functional/services/svl_reporting.ts` and
`x-pack/test_serverless/api_integration/test_suites/common/reporting/management.ts`
in the same way even though they not run in MKI projects today. This
will hopefully avoid the same set of problems when the tests eventually
get re-enabled for MKI runs.
## Summary
This PR adds more functional ui tests around trained model listing and
what a full access user vs a view only user can see and do.
There is more of a focus on the Add Trained Model Flyout, as that is a
newer feature.
### Details
- Add data test subjects for:
- space aware warning "copy"
- add trained model button
- trained model flyout
- trained model flyout close button
- trained model flyout Elser model "copy"
- trained model flyout `Manual Download` tab
- trained model flyout `Click to Download` tab
- trained model flyout `Choose Model` panels
- trained model flyout `Download` button
- trained model flyout eland pip install code block
- trained model flyout eland conda install code block
- trained model flyout eland example import code block
Note: Added a helper function to make the dynamic data test subjects for
the `Click to Download` and `Manual Download` easy to reason about. It
is used in the DOM and within the test service method.
- Add tests to the `trained models` suite
- Add new provider for `Add Trained Model` Flyout
- add service methods:
- asserting that while an ml power user can access two tabs within the
flyout, a viewer user can only see 1, the manual download tab.
- to open and close the flyout
- assert the download button exists
- assert e5 panels exist
- assert eland python code blocks exist
- assert elser model copy
- assert elser panels exist
- Modify the api's `deleteIngestPipeline` as it was failing in CI, when
an `it` block failed
- No you can choose whether to assert and it the assertion is made, the
logging occurs as well.
- Modify `trained models` provider, adding:
- method to close the modal that pops up when a model requested to be
deleted, cannot be
- method to select a model by name
- Modify `trained models table` provider, adding:
- method asserting the contents of the warning for why a given model
cannot be deleted, upon attempting to delete said model that resides in
a space or spaces, that the current user cannot see.
---------
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
## Summary
The current way we are using in our Cypress tests to delete exception
list, is not working on MKI environments. This is because we are trying
to modify internal indexes directly, something that is completely
forbidden in this real Serverless projects.
To solve the issue, we are using our APIs to perform the deletion
actions.
In `add_edit_exception.cy.ts`, we are also deleting the deletion of a
specific list from the beforeEach hook, since we are doing that already
using `deleteExceptionLists()`
In `manage_exceptions.cy.ts`, we are deleting the
`deleteEndpointExceptionList()` since seems that we are not creating an
endpoint exception.
- Addresses a part of https://github.com/elastic/kibana/issues/177156
## Summary
This PR changes how the total hits counter is reported in Discover for
ES|QL mode. The previous logic could be misleading as the received
documents count sometimes was not the same as the shown total hits
counter. Often it's because for ES|QL queries without sorting, separate
requests might return different result.
Before:
Number of received docs in Discover was considered only as "partial"
result for total hits. The final value was coming from UnifiedHistogram:
- if chart is visible and histogram => total hits are based on the
result of the histogram fetch request
- if chart is visible and it's not a histogram but based on discover
fetched records => total hits are calculated from the number of records
- if chart is hidden => total hits are based on the results of the
separate request for getting the count only
After:
Number of received docs in Discover is considered as "complete" result
for total hits. Changes for UnifiedHistogram:
- if chart is visible and histogram => logic stays but the histogram
total hits count is ignored on Discover side
- if chart is visible and it's not a histogram but based on discover
fetched records => logic stays but the histogram total hits count is
ignored on Discover side
- if chart is hidden => this request is removed completely.
It's a proposal. Happy to discuss.
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
This PR enables Timeline to have its own expandable flyout, independent
from the Security Solution app level flyout. This previous
[PR](https://github.com/elastic/kibana/pull/176457) added support to the
`kbn-expandable-flyout` package to be able to show multiple flyout at
the same time.
This PR focuses on:
- changing the location where we use the `<ExpandableFlyoutProvider>` to
wrap only the Security Solution pages. instead of the entire Security
Solution application
- wrapping `Timeline` with its own `<ExpandableFlyoutProvider>`
- opening the new expandable flyout from timeline for alerts, users and
host!!
### Notes
- the new expandable flyout opened from `Timeline` is saved in the url
under a new `timelineFlyout` parameter. The other Security Solution
flyout stays saved under `eventFlyout` so both can be displayed at the
same time
- introduced a new feature flag called
`expandableTimelineFlyoutEnabled`, enabled to `false` by default. The
code uses this flag in combination with the already existing
`securitySolution:enableExpandableFlyout` advanced settings to toggle
on/off the expandable flyout in `Timeline`
I had to make a small change to the timeline `z-index` value, from its
hardcoded value of `1000` to now `1001`. At the same time I'm setting
the `z-index` of the `eventFlyout` to `1000` and the `z-index` of the
`timelineFlyout` to `1002`. Finally, I changed the `z-index` of all the
other flyouts opened from the `Take action` button in the footer (like
_Add to new case_, _Add rule exception_...) to `1003`. This was the only
way to get the order correct after page refresh, and also work in
Serverless which has a different top level layout (for the top bar and
the left navigation panel).
### Testing
Make sure you have the flag turned on in your `kibana.yml` file:
`xpack.securitySolution.enableExperimental:
['expandableTimelineFlyoutEnabled']`
While the code changes are pretty minimal, emphasize should be done on
testing:
- verify that the non-timeline expandable flyout behavior hasn't changed
(in the Explore, Rule Preview, Alerts pages...)
- verify the advanced settings correctly toggles on and off the
expandable flyout for both the Security Solution app and Timeline
- verify the expandable flyout correctly shows up in Timeline on all the
pages where Timeline is present
- verify both flyout can be shown at the same time
- verify refreshing the page reloads correctly all flyouts open
- verify copying the url or using the Share Alert button at the top can
be correctly reopened in another tab
### 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
### TODO
- [x] fix unit tests
- [ ] fix e2e tests
- [x] figure out how to fix the UI in serverless (the flyout is
currently behind the left navigation)
Before change:
3b89f87f-d1fa-4635-8ff7-855795eb3796
After change:
6b341f11-054c-4885-b496-006f37b8d572
Serverless
df414140-31df-4941-869e-c177cfedd805
https://github.com/elastic/security-team/issues/7464
Details of file changed in [the comment
below](https://github.com/elastic/kibana/pull/177087#issuecomment-1988642537)
Closes https://github.com/elastic/kibana/issues/164104
## Summary
**Replace "Download CSV" with "Generate CSV report" to export a CSV file
from saved search panel, deprecate "Download CSV", use a config flag for
providing the deprecated feature.**
This PR uses the `xpack.reporting.csv.enablePanelActionDownload`
kibana.yml setting, which was previously unused, for choosing behavior
of CSV export in a Dashboard saved search panel, and sets the default
value to `false`. The options allow the user to download a CSV file
without creating a report (deprecated, support will be removed in the
future) or to generate a CSV report (default).
1. Use the config as a flag to switch between implementations:
- downloading a CSV file without a generated report
- generating a CSV report
2. Updated documentation
3. Refactored / cleaned up tests
4. Increased API test coverage in Serverless
5. Better error handling in
`packages/kbn-reporting/public/reporting_api_client.ts`
### Checklist
Delete any items that are not applicable to this PR.
- [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/packages/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)
## Release Note
Kibana CSV Reporting offered a feature allowing users to download a CSV
file from a saved search panel in a dashboard, without having a report
generated. This feature is now deprecated. Now, when users need to
access saved search data from a dashboard panel as CSV, a normal report
will be generated. To access the deprecated functionality, you can add
`xpack.reporting.csv.enablePanelActionDownload: true` to kibana.yml, but
this ability will be removed in a future version of Kibana.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
I've always been annoyed with these warnings that appear in the console
when starting Kibana:
<img width="1344" alt="Screenshot 2024-03-22 at 3 40 09 PM"
src="9e722ea9-8ca4-47de-8f28-ca511d6e7194">
The trouble is, it's been nearly impossible to find these in the code.
While working with some changes to the `ml` plugin, I noticed something
familiar:
<img width="925" alt="Screenshot 2024-03-22 at 3 39 56 PM"
src="5d69c693-512b-4794-9bd7-f2d12c693d7d">
So with a smaller haystack, I was able to find and fix them.
<img width="671" alt="Screenshot 2024-03-22 at 4 51 43 PM"
src="70db7016-eb04-4171-a4a8-18e4df7131ae">
