Move new_vis_modal to visualizations plugin.
These removes one import from visualisations plugin to kibana/
showNewVisModal() is part of the plugin contract and plugin dependencies are provided implicitly.
# Conflicts:
# x-pack/plugins/translations/translations/ja-JP.json
# x-pack/plugins/translations/translations/zh-CN.json
* [ML] (Accessibility) Fix page heading structure
* [ML] Fix file datavisualizer SCSS import
* [ML] Switch to EuiTitle for influencers list and data viz cards
* [ML] Fix positioning of chart tooltip in Single Metric Viewer
- Move UI metric constants into public directory.
- Convert server-side code to TS, largely with use of any.
- Remove unused sendPut method from API service.
- Update http error handling to consume NP http service errors.
- Refactor DI pattern of Index Mangement extensions to require various NP service dependencies.
- Inject NP http service into Index Management extensions. Remove dependency upon Angular's $http.
* chore(NA): introduce futureEmitAssets option. chore(NA): bump related webpack dependencies.
* chore(NA): remove minimizer compress on dll compiler.
* chore(NA): re enable dead code removal.
* chore(NA): remove not needed file
* docs(NA): add todo on dll compiler to remove this on webpack 5
* Replace uses of chrome.getBasePath with NP equivalent
* Prefer functional form of ApolloLink creation
Mainly because there's no mention of direct instantiation in their
documentation.
* Replace uses of chrome.getBasePath with custom hook
This ultimately uses useKibana() for now, but that will change in the
future.
* Refactor our frontend lib composition to use core instead of chrome
This gets rid of our last usage of chrome.getBasePath.
* Remove unused ui modules
These have been unused since we excised our dependence on angular.
* Remove unused mocks
chrome.getBasePath has been deprecated and is unused within SIEM.
* Mock core HTTP service in tests
Now that some of these components are implicitly using the http service
to get the app's basepath, we need to mock it out.
There is a more robust set of mocks provided for core services, but I
don't want to pull that in yet as we're only using this single method,
and it should be addressed when we start paring this down to more
fine-grained mocks for each test/component.
* Define singleton module for our kibana services
The app is currently retrieving services in one of three ways:
* from the ui/new_platform module
* from 'ui/chrome'
* from the KibanaContext, via hooks or HOCs
This module is the first step in consolidating those. We'll initialize
it on plugin start(), and then populate the context with the same
references. ui/chrome will eventually be removed.
* Populate KibanaContext via our services module
This ensures that all references to these services are coming from the
same place, which is easier to reason about and also easier to
mock/test.
* Move our kibana-based hooks to a more appropriate location
These hooks all use the `useKibana()` context hook under the hood, so
it's slightly less confusing to nest them under lib/kibana/hooks.
* Remove outstanding uses of chrome.getUiSettingsClient
This uses our services singleton to fetch the NP UISettings client
directly, rather than through ui/chrome.
Modifies the singleton to export a function rather than a variable, as
this allows us to guard against any misuse, and allows us to mock the
module more easily in tests as well.
* Replace ui/i18n with NP equivalent
The i18n provider comes from the core i18n plugin, now.
* Replace use of ui/chrome in new overview page
* Replace use of npStart with our facade
These are functionally equivalent, but getServices is under our control
and won't go away.
* Retrive data plugin dependencies through consistent code path
One of our components was destructuring and then re-exporting
ui/new_platform code. This works, it's just a little surprising. This
refactors the code to use getServices and useKibana() as appropriate.
* Pass kibana services to our React component
We have a few very specific needs for uses of these services outside of
react, so I've decided to keep that singleton as small as possible until
we can refactor out their need.
* Remove uses of kibana services during module evaluation
There was an issue here where we were calling into UISettings when our
redux code was imported. With the ui/chrome module this just worked, but
now that we're using getServices, those calls were blowing up as the
services had not yet been initialized.
The current solution is to defer the initial state creation (which
accesses UI settings) to start time, when we have our UISettings service
available.
This refactored the default_date_settings helpers and tests pretty
significantly: I consolidated those helpers into two functions for
timeRange settings and refreshInterval settings, respectively.
* Replace static settings functions with short-circuited regular functions
Adds tests for this invocation, too.
* Refactor getIndexPatterns to accept the savedObjects client
This removes one more use of our global getServices helper, and instead
pulls from the kibana context.
* Clean up our use of the data plugin
This removes our one use of getServices with the data plugin, opting
instead for a `useKibana` hook in the calling component.
This cleans up any unnecessary mocks, and converts the needed ones to
mock out useKibana, for now.
* Limit what we can retrieve from getServices
All these uses are now code smells. To prevent their proliferation,
let's try to whitelist which services are available to just what we
need.
* Replace breadcrumbs with NP equivalent
* Convert our getServices module to a singleton Class
Rather than relying on our build system for proper closures, this
enforces that behavior via plain ol' javascript.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Should address #56352.
I did a look up and it seems like only id and title a really used in case that savedObjectsCache is used. So I simply limited that request to fetch only title
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Revert "force yarn 1.21.1 until we can handle invalid output of 1.22.0 (#56914)"
This reverts commit 5686010b46.
* move the --json argument before `workspaces` so it still works
* update kbn/pm dist
(cherry picked from commit 12de6a8459)
Some fixes for #54405.
* Use the `popoverPositionFluid` method of `EuiPopover` to properly position the arrow based on where the popover was opened
* Rearrange the variable declarations and effects in the popover index
* Create a `Contents` component to separate the internals of the popover from the index, where the poisitioning is done
* Add a story to show the contents rendering
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* [Telemetry] Report Kibana distro in local collectors + Usage Collectors in TS
* Ensure isReady is a function
* Move CollectorSet tests to TS + Jest
* Fix test
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Set filterByMapBounds to default constant if no arg passed
* toggle accidentally refers to props instead of state for filterByBounds. update to state
* Review feedback. Remove extra filterByMapBounds
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
We're seeing occasional "Error: Call retries were exceeded" exception
with Terser, which should be resolved by
abfd950620,
first included in 2.3.4
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Add Unit tests for the QueryContext class that was missing testing. This would have caught #56612
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
If we don't specify an undefined content-type like so, the client
attempts to convert our form data into a JSON string, and the backend
returns an understandable 415.
This fixes rule imports.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Fixes an issue where the Signals count spinner can spin forever
Per the animated gif below, in `7.6` `BC 4`, the `Signals count` spinner on the Overview page spins forever until the signals index is created (in the current Kibana space):
The `Signals count` spinner will spin forever until the user clicks the `Detections` tab, which-in turn creates the signals index (if it doesn't exist), per the animated gif below:
This behavior is an issue because:
- When a fresh deployment is created on Elastic Cloud, a user won't understand why the `Signals count` widget is always spinning on the `Overview` page. (The user must click the `Detections` page to resolve this.)
- In deployments where authentication is disabled, or, for _reasons_, a Detections index will never be created, the `Signals count` spinner on the Overview page will always spin.
To reproduce:
1. Spin up a new `7.6` `BC 4` deployment on Elastic Cloud
2. Login to Kibana for the first time
3. Navigate to the SIEM app
**Expected result**
- All histograms on the Overview page eventually stop displaying their respective loading spinners
**Actual result**
- The `Signals count` widget spinner spins forever. (The user must click the `Detections` tab to create the signals index.)
## Deleting the signals index
To reproduce the issue above when a signals index has already been created (by clicking on the Detections tab), run the following from the Kibana `Dev Tools` `Console`:
```
DELETE /.siem-signals-default-000001
```
It is also possible to reproduce this issue by creating a new space, because it won't have a signals index.
https://github.com/elastic/siem-team/issues/514
When upgrading to the next major version, users should first upgrade to
the last minor in the previous release. In 6.x this is 6.8.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
