Using the field_capabilities API added in the previous commit, this commit enhances
the client side index pattern object with information about the
searchable and aggregatable status of each field in the index pattern.
We then use this information to filter out non-aggregatable fields from
the vis editor so that users won't accidentally select them and get
nasty errors. An example of a non-aggregatable field would be a `text`
field without fielddata enabled (which is the default).
I also added the searchable and aggregatable flags to the index pattern
page so users can see the status of their fields. I removed the `indexed`
column because it was mostly redundant with `searchable` and I needed
the horizontal space.
The addition of the searchable and aggregatable properties for index
pattern fields would require users to manually refresh their field list
when upgrading to 5.0. This commit also adds a check for those properties and
if they're missing it automatically refreshes the field list for the
user in a seamless manner.
This adds a simple API for getting the searchable/aggregatable status of
a list of fields in a given index, list of indices, or index pattern. In
the future this will probably evolve into a full blown fields info API
that we can use when removing the index pattern mapping cache. For now
though it's built to provide the minimum info needed to fix
https://github.com/elastic/kibana/issues/6769
Usage:
The API exposes a single GET endpoint.
```
GET /api/kibana/{indices}/field_capabilities
```
`indices` can be a single index, a comma delimited list, or a wildcard
pattern
Example response:
```
{
"fields": {
"imsearchable": {
"searchable": true,
"aggregatable": false
},
"imaggregatable": {
"searchable": true,
"aggregatable": true
},
}
}
```
The opacity of the items that are dimmed on a chart can now be configured. This is useful for users who want to increase or decrease the contrast between the element under focus and the other elements.
With the new "rendered" event, the listener added in the handler was not being cleaned up. This changes it to use the handler's `binder`, which will cleanup the listener when `handler.destroy()` is called.
When splitting the input/output modules into an `initializeInput` and `getInput` pair, it was changed to an esModule. This means that you can no longer require is and execute it's default export directly, as was being done in the console's settings module.
* Legends will overflow along the y-axis, maintaining a 100% height of the page
* With these changes, space-between would at times place the text out of view
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
This commit reverts a change to use the ingest API when deleting index
patterns via the Kibana UI. Back when I was building the Filebeat wizard
it made sense to try to delete any index templates or pipelines that may
have been created along with an index pattern. But now that we're only
shipping with CSV Upload, and we don't delete the actual indices that
CSV upload creates, it doesn't make much sense to delete the template.
Now we'll treate the indices and templates consistently.
This also fixes an issue where users would get a fatal error if they
were using Security and they didn't have permissions to delete
templates. Every index pattern deletion would also attempt to delete an
associated template, so if the user didn't have the correct permissions
they would get a 403.
Related: https://github.com/elastic/kibana/pull/6457
The kbn-dev-tools-app directive renders a navbar above each devtool, giving it breadcrumbs and links to the other devtools. This collides with the toolbars used in devtools like console and causes two mostly-empty toolbars to be stacked.
To fix this, we are merging the navbar from kbn-dev-tools-app and the toolbar provided by the devtools into a single kbn-top-nav toolbar. Console already used the kbn-top-nav directive for it's navbar, so kbn-dev-tools-app just needed to be extended to consume and render the kbn-top-nav configuration (a controller in this instance).
