* [dev/notice] add scripts for generating NOTICE.txt file
* [notice] react-resize-detector@0.6.0 was removed in b445389b79
* [notice] move notice text into relevant source
* [dev/notice] Generate NOTICE.txt file
* [jenkins] verify that notice.txt is up to date in CI
* [tasks/notice] update test to use new NOTICE.txt file
* [dev/notice] update company name in NOTICE.txt
* [notice/cli] exit with 0 when --help requested
* [notice/cli] add helpful logging
* [notice/cli] use --validate flag name instead
* [notice/cli] simplify NEWLINE_RE, ignore obscure line endings
* [utils/decode_geo_hash] fixup comment
* [utils/decode_geo_hash] remove useless comment
* [ui/config] extract core config logic into vanilla JS UiSettingsClient
* [ui/config] stub the uiSettings individually for each test
* [ui/config] ensure that change events are emitted sync
* [uiSettings/batchSet] send request immediately, buffer when needed
Rather than buffering all writes and waiting 200ms before sending config
request to the uiSettings API, send updates as soon as they are received
but buffer updates that are received while another request is in
progress. This eliminates the 200ms delay and ensures that the server
receives requests from a single user in the correct order in the
unlikely event that many calls to `config.set()` are made in a very
short period of time.
It is not very useful to have:
* shardTimeout disabled if requestTimeout is enabled (means infinite es overruns)
* shardTimeout > requestTimeout if both enabled (means finite es overruns)
* shardTimeout < requestTimeout if both enabled (means partial results from es?)
The only option that really makes sense is to have shardTimeout === requestTimeout, so that's what I've done here.
* throw exeception when unable to migrate panel data
* catch migrate exception and show toast
* remove unneeded conversion to string
* fix jest test
* use forEach instead of map
* fix jest tests
* move toast and window.location change to constructor
While in production, we use the `no-warnings` flag to prevent warnings from going to STDERR, and instead capture the warning events using our logger. Some warnings are helpful in debugging and/or identifying problems in production, like UnhandledPromiseRejection. Deprecation warnings are not an immediate problem, but an issue with upgrading to the next version of Node. These warnings will continue to be presented to developers, just not for production users.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
* add more output
This will let us know if the filter is failing to be added on the
visualization before being saved.
* run 20x
* go back to single run
The addition of the optional flag to disable leading wildcards inadvertently broke exists queries, which are accomplished in kuery with the fieldName:* syntax.
Lukas and I chatted over Slack and we both agreed it didn't really make sense to apply query:queryString:options to query_string filters. If someone is using the advanced query DSL editor to create a query_string filter they probably want full control over it.
This is a breaking change so it will only go in 7.0. In 6.x users should use one of the workarounds.
* advanced setting to control search request preference
* add header tests
* add sentince about caching to description
* change courier:setRequestPreference to list and add courier:customRequestPreference
* update setting text
* [kbn-dev-utils/procRunner] try using execa to avoid never-exitting procs
* [kbn-dev-utils/procRunner] don't listen for close event, rely on stdio streams ending
