Introduces bin/kibana-keystore providing create, list, add, and remove actions.
Settings stored within the keystore will be loaded at runtime.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
Update Docker docs for 6.0.0 and image flavours
* Use Compose v2 in Docker examples
* Use US spelling in Docker docs
* Link to www.docker.elastic.co in docs
* [timelion] remove last remaining amd modules
* [eslint-config-kibana] remove env.amd
* [webpack] use absolute loader names
* [webpack] remove absolute node_modules/ imports
* [webpack] upgrade to webpack 3
* [uiFramework] make webpack build compatible with v3
* [eslint-import-resolver] use https://github.com/elastic/eslint-import-resolver-kibana/pull/21
* [baseOptimizer] don't break when pkg has no dependencies
* [optimize] remove unnecessary json-loader
* [optimize] remove local references to webpack vars
* [eslint] upgrade to eslint-import-resolver-kibana 0.9.0
* [baseOptimizer] comment tweaks
* [baseOptimizer] remove loader pinning
In webpack 1 the loaders defined here were resolved relative to the file they were going to load, which meant that plugins in other projects could accidentally overwrite the loaders Kibana was trying to use, which is why the aliases were used to enforce proper resolution.
In webpack 2 loaders are now resolved relative to the webpackConfig.context, which is set to the root of the Kibana repo. See https://webpack.js.org/configuration/module/#useentry
* [webpack] rely on kibana webpack shims before checking node_modules
* Check sort:options for Discover default sort order
I went back and forth on a lot of different solutions for this.
Initially I thought it would make sense to just allow users to set a
default saved search in Discover. There were some problems with that
approach though. It would change the default workflow in Discover.
Instead of starting with an unsaved search, users would be editing a
saved search by default. I could see this leading to a lot of
unintentional changes to the default. The settings from the default
saved search also wouldn't carry over to new searches, which I think
would be desirable most of the time.
I also considered adding a new advanced setting for specifying a default
sort field/direction. This kind of setting would make more sense at the
index pattern level though. One field may not be valid across all index
patterns.
So I ended up going with the simplest solution. It solves the issue
identified by the author of the linked issue and nothing more. If a sort
order is specified in the existing sort:options advanced setting, we'll
use that direction when sorting on the index pattern's timestamp field
by default.
Fixes https://github.com/elastic/kibana/issues/5164
* Create a new advanced setting instead of re-using sort:options
* Just pass a default order
* Re-enable filter editor suggestions
* Use search instead of include
* Escape query
* Show spinner
* Use include rather than search
* Add additional regex and explanation for parameters
* Add suggestions API test
* Make sure test actually runs
* Use send instead of query
* Fix suggestions API test
* upgrade leaflet modules to 1.x latest
* fix css for leaflet controls
* update draw options so it is easier to see polygon when drawing
* fix chrome touch issues with closing polygon in leaflet draw
* use canvas renderer
* use leaflet-responsive-popup to avoid tooltip cutoff
* remove radius configuration from leaflet heatmap
* make blur a factor of radius. Set maxZoom to map zoom since new values are calculated per precision
* use _.get to avoid error, cannot read property of undefined
* add cluster size slider
* experiments with image differences
* onload not onLoad
* use canvas dimensions
* compare map canvas to stored PNG of map canvas
* remove pixelmatch from project dependecies
* fix broken test - rounding error
* add expected image tests for geohash layers shaded circles and geohash grids
* bump z-index of vis-spy
* update functional test expected data
* update to leaflet 1.2.0
* revert to leaflet 1.0.3 and update expected data set for map functional tests
* test geohash_layer heatmap in unit test
* update region_map functional test since it can not longer pluck map vectors from DOM
* update documentation
* add markdown functional test
* update markdown vis to use markdown-it
* migrate markdown angular filter to markdown-it
* place other uses of marked and remove dependency
* update breaking changes documenation and set linkify to true
Fixes#13563
Brings additional attention to the fact that Kuery uses implicit ANDs whereas Lucene query syntax uses implicit ORs, which could confuse users if they're not aware of the difference.
* Change use of all_fields in highlight_query to default_field
* Remove highlight query and option
* Fix tests
* Remove unused setting
* Remove lingering references to all_fields
* Configurable custom response headers for server
The server.customResponseHeaders configuration allows users to configure
custom headers to send on all responses to the client from anywhere in
the Kibana server.
This can be useful for setting headers like x-frame-options when you
don't want people embedding even Kibana dashboards in an iframe.
* Consistent header overriding and explicit unknown
The documentation for setting Kibana options with environment variables under
Docker was brittle and difficult to maintain. Rather than list every option,
this change describes the method by which they are defined, thus avoiding the
need to edit the docs in multiple places when a new option is introduced.