- helper functions for dynamic css class names
- notifications: reposition the countdown button outside of the button group
- notifications/buttons: bootstrap primary/default button classes for custom actions
Several tests have been failing recently with "Error: Unexpected request: POST /api/kibana/settings/shortDots:enable, No more request expected" which seems to be caused by the field chooser tests calling `config.set('shortDots:enable', origValue)` in the test cleanup task. Rather than investigate it further I avoided the need to call `config.set()` by stubbing the `config.get()` method.
This commit allows Kibana scripted fields to be written in any language
that has been enabled for inline scripting in ES. By default, that's
expression and painless in 5.0. Groovy and other languages can be
enabled in the Elasticsearch config. However, I've spent the most time
trying to optimize the experience for painless and expression since
those are the two sandboxed languages we should be encouraging people
to use.
Field type options are limited per language based on what makes sense
for that language and for scripte fields in general. For instance,
expression scripts can only be number fields because expressions only
return numbers. No scripted fields can be geo_points, because the geo
aggregations Kibana uses don't support scripts.
This UI enhancement uses the new script languages API added in the
previous commit to get the list of inline scripting languages
dynamically.
To provide additional language options for scripted fields, Kibana needs
to know what languages are available for inline scripting in
Elasticsearch. This new Kibana API grabs up to date information from
Elasticsearch and provides it in an easy to digest format for the UI.
The response body from the API is a simple JSON array with a list of
languages that are enabled for inline scripting. The API also filters
out languages that don't make sense in scripted fields, like 'mustache'.
An example request might look like this:
`GET /api/kibana/scripts/languages`
200 OK
`['expression', 'painless']`
Bind Kibana server to localhost.
This is a breaking change. Now, Kibana will not be accessible to remote users by default. To enable this, the server.host parameter needs to be configured.