* Add shims for new platform structure
Defines both our Plugin class and the factory function.
* Simplify server init code path
We were doing some work with server, then dropping into another function
to further mutate it. I'm moving this all to the same level
(initServerWithKibana) to make decoupling from Hapi simpler to follow.
* Remove unnecessary casting
Server has newPlatform on it, now.
* Remove unused arguments
These had their usage removed in #36662 but their signature remained.
Since we're trying to pin down the existing interface with hapi, this is
just noise that should be deleted.
* Remove unneeded destructuring
This was only needed for a type assertion, originally.
* Document current interface with hapi via ServerFacade
This is everything we're using from hapi's server right now. The next
step is moving what we can to the new platform, and abstracting the
rest behind a facade layer.
* Include NP plugin in initialization path
* Instantiates plugin and passes NP modules
* We're just passing the LoggerFactory from the init context, for now.
* Whitelist functionality from Server, pass through as ServerFacade
* This will verify our facade at runtime in addition to typechecking
* Uses Pick and Partial to use existing types while shimming properties
as we go
* Remove redundant logging mechanism
We were logger in two different ways, but we can move to the NP version
now that it's ready.
* Bind server's route function context
This was causing a test failure and needed to be bound similarly to the
register function. Slight rename of variables as well.
* Type Hapi.Request usage via RequestFacade
This is everything we're currently using from Hapi.Request; as we move
things away we can update this interface and let TS tell us what's
broken.
Remove any typing of our request payloads
These _can_ have fields like `variables` and `operationName` from
graphQL, or they might not. In the majority of cases the payload was
typed as any, and to cut down on churn and because I have no confidence
in typing each individual request, we're going to make that the default.
* Inline our GraphQL Hapi plugin
A la uptime, this effectively just moves the call to server.route() into
the function itself, rather than registering a Hapi plugin that
ultimately does the same.
* Remove register from our list of Hapi dependencies
This was only used to register our GraphQL plugin(s), which are now
inlined and use `route`.
* Invoke existing init path from plugin's setup
This isn't the final format as we're eventually doing away with __legacy
entirely, but this makes our plugin 'live' and is a step in the right
direction.
* Remove usage of Pick in favor of a type assertion
The onus here should be on the shim invocation, not the plugin itself.
* Pass existing NP modules into our plugin
Another step toward the proper plugin signature.
We're needlessly destructuring coreContext just to get the logger and
pass it right back in. The other logger usage will be removed momentarily when we change the signature of `initServerWithKibana`.
Also adds core and plugins to our setup method, which are currently
unused.
* Remove dependence on newPlatform property in Server
We now get these through NP's initializerContext, so we do that in the
plugin now instead. The extra parameters are gross but temporary
(initServerWithKibana will eventually go away), and
it's much better to shrink the size of ServerFacade.
* Remove unused mocking fn/logging/tests
These are relics from the initial graphQL implementation and are no
longer used.
* Move log statement into plugin
Makes more sense to decorate the init invocation than to log 'start'
from outside and 'end' from inside.
* Fix shape of our InitializerContext
While PluginInitializerContext type has the env property, the
newPlatform object on the Server has it in a different shape.
* Ensure our request payloads are typed
Rather than the free-for-all of `any`, let's instead type our payload as
unknown and actually name the request types whose payloads are being
reached into. A type assertion in the resolver for these requests is the
secret sauce here.
Fixes an issue where an empty `Source` or `Destination` container is rendered by
the Timeline row renderer when events have `source.port` or `destination.port` populated,
but the corresponding `source.ip` or `destination.ip` is not.
### Before Chrome `78.0.3904.97`
![chrome-before](https://user-images.githubusercontent.com/4459398/68985053-fd26ec80-07d0-11ea-99e3-1180a3e9d7fb.png)
### After Chrome `78.0.3904.97`
![chrome-after](https://user-images.githubusercontent.com/4459398/68985058-0912ae80-07d1-11ea-990a-1a66802cad0e.png)
## Details
The following JSON is from the event shown in the screenshots above:
```
"destination": {
"port": 53
},
```
In the JSON above, the `destination.port` field is populated, but the
`destination.ip` field is **not** populated.
The `destination.port` in the event is expected to be rendered in the
"before" screenshot above, but an empty `Destination` label is rendered
instead.
## To reproduce:
1. Create a new timeline with the following KQL:
```
destination.port: * and NOT destination.ip: *
```
**Expected Result**
- The `destination.port` contained in the event is rendered in the `Destination` container
**Actual result**
- An empty `Destination` is rendered, per the "before" screenshot above
## Other Corner Cases
An analysis of real data performed while desk testing this PR revealed other
corner cases in real-world data, including port arrays with `null` values.
The types and implementaion were updated to reflect the reality of the data
found during desk testing. Unit tests were added to cover these cases.
### After Firefox `70.0.1`
![firefox-after](https://user-images.githubusercontent.com/4459398/68985063-10d25300-07d1-11ea-9c17-d962c0f1015e.png)
### After Safari `13.0.3`
![safari-after](https://user-images.githubusercontent.com/4459398/68985067-162f9d80-07d1-11ea-8773-d3e71a84a440.png)
Note: This PR was NOT tested in IE 11, due to unrelated IE 11 issues with dependencies in `master`
* https://github.com/elastic/siem-team/issues/476
* [Maps] prevent users from overflowing URL when filtering by shape
* small fix
* fix jest test
* update warning message
* update overflow error message
* [NP:Kibana:homeAPI] initializes a new plugin (WIP)
* Typing
* New plugin tutorials not needing server working
* Retains legacy tutorial registration and adds new route for new platform tutorial plugin registrations
* Adds comment on where to pre-register general non-plugin specific tutorials
* Converts TutorialsPlugin to TutorialsRegistry service in new Home plugin
* Changes call to location of registerTutorial in registerTutorials
* Adds console log for the home plugin that's returning an empty object
* Removes async from setup and start methods in the home plugin and the tutorials service
* Starts writing tests and creating mocks
* Adds basic tests for TutorialRegistry service
* Adds basic tests for TutorialRegistry service
* Adds test for route
* Adds mocks and tests for the home plugin
* Adds home plugin to security plugin and registers scoped tutorials service
* Removes incorrect addition to src core server
* Fixes type errors
* Deletes unused code
* Deletes duplicate golangMetricsSpecProvider registration
* Nests tutorials service in a tutorials key in the home plugin, changes api http routes for legacy platform and NP
* Changes url variable names
* create modelMemoryLimit estimation endpoint. add value to form
* add validation for model memory limit field
* update jest tests
* update validateModelMemoryLimitUnitsUtils to be more generic
* add placeholder and validation with helpText to modelMemoryLimit field
* update endpoint name to estimateDataFrameAnalyticsMemoryUsage for clarity
* tweak modelMemoryLimitEmpty check in reducer
* add tests for modelMemoryLimit validation
* WIP: Notice banner for OSS folks
* Add telemetryNotifyUserAboutOptInDefault to injected vars
* add userHasSeenNotice check
* More WIP on banner notice component
* Text changes on screens
* make userHasSeenNotice flag work
* Finalzed splash text + checking new flag
* Consolidating banner calls and saving status of opt-in notice
* Conditionally remove the banner and add some code docs
* Fixing prior welcome tests
* api integration test for user has seen opt in
* change post method to put in ui
* unit test for get_telemetry_notify_user_about_optin_default
* Ignore TS woes
* Adding new tests and snapshots for opt-in banner component
* Notice banner test
* Translation miss
* More opt-in tests
* increase types usage
* roll back core server api change
* update snapshot
* Prop name change + snapshot updates
* Better explanation about the Prettier recommendation (extension vs. NPM module)
* Contributing docs: Add side effect from using the Prettier extension
* Use a basic monitoring user for tests
* Rework this a little to fix the issue that the tests aren't working properly
* I think this is what we need to fix the tests
* Switch this order, since these tests cause a weird login loop in the current order
* Add error messages when setup mode is not enabled, disable it for users without the necessary permissions, and change one query to relax the privilege requirements
* Fix default value
* PR feedback
* Forgot to update this part
* Fix tests
* Additional validation for elasticsearch username
If "elastic" user is set in config:
* In dev mode, throws an error
* In prod mode, logs a deprecation warning
* Fix user for functional tests
* Revert last two commits
Revert "Fix user for functional tests" and
"Fix user for plugin functional tests in Jenkinsfile"
* Change elasticsearch creds for test server
Now uses "kibana" user instead of "elastic" user
* Fix plugin API functional tests
* Fix PKI API integration test
* Change log messages, now conditional on `dist: false` not `dev: true`