[[breaking-changes-7.0]]
== Breaking changes in 7.0
++++
<titleabbrev>7.0</titleabbrev>
++++

This section discusses the changes that you need to be aware of when migrating
your application to Kibana 7.0.

See also <<release-highlights>> and <<release-notes>>.

[float]
=== Removed support for tribe nodes
*Details:* Elasticsearch 7.0 removes the tribe node feature, so Kibana removes it as well.

*Impact:* You must remove any tribe node configurations in Kibana. Consider using <<management-cross-cluster-search>> instead, which does not require kibana.yml configurations in Kibana.


[float]
=== Removed support for running Kibana with a global Node.js installation
*Details:* Previous versions of Kibana would fallback to using a global installation of Node.js if the distribution included with Kibana was not found.
Kibana 7.0 will only use the Node.js distribution included in the package.

*Impact:* There is no expected impact unless Kibana is installed in a non-standard way.

[float]
=== Removed support for using PhantomJS browser for screenshots in Reporting
*Details:* Since the first release of Kibana Reporting, PhantomJS was used as
the headless browser to capture screenshots of Kibana dashboards and
visualizations. In that short time, Chromium has started offering a new
headless browser library and the PhantomJS maintainers abandoned their project.
We started planning for a transition in 6.5.0, when we made Chromium the
default option, but allowed users to continue using Phantom with the
`xpack.reporting.capture.browser.type: phantom` setting. In 7.0, that setting
will still exist for compatibility, but the only valid option will be
`chromium`.

*Impact:* Before upgrading to 7.0, if you have `xpack.reporting.capture.browser.type`
set in kibana.yml, make sure it is set to `chromium`.

[NOTE]
============
Reporting 7.0 uses a version of the Chromium headless browser that RHEL 6,
CentOS 6.x, and other old versions of Linux derived from RHEL 6. This change
effectively removes RHEL 6 OS server support from Kibana Reporting. Users with
RHEL 6 must upgrade to RHEL 7 to use Kibana Reporting starting with version
7.0.0 of the Elastic stack.
============

[float]
=== Advanced setting query:queryString:options no longer applies to filters
*Details:* In previous versions of Kibana the Advanced Setting `query:queryString:options` was applied to both queries
and custom filters using the `query_string` query. This could cause errors if a custom filter used options that
conflicted with the Advanced Setting. In 7.0 `query:queryString:options` will no longer be applied to filters so that
users can have full control over their custom filters.

*Impact:* You must ensure that any saved searches with a `query_string` filter aren't relying implicitly on
`query:queryString:options`.

[float]
=== Advanced setting query:queryString:options no longer applies `default_field: *` by default.
*Details:* Elasticsearch removed the ability to create indices with an _all field in 6.0. As a result, a user could end
up with a mix of indices with and without _all fields if they upgraded from an older version of ES. This could lead to
inconsistent highlighting in Discover. To work around this issue we added `default_field: *` to query:queryString:options
to force consistent querying across indices with and without _all. In 7.0 the _all field will be gone from all indices
so we no longer need this workaround.

*Impact:* Since we'll no longer send the `default_field` parameter in Kibana's query_string query, Elasticsearch
will use the index setting instead. The default for the index setting is also `*`, so most users should not be impacted.
If some of your indices have a non-default `default_field` setting, you may want to update it or re-add the parameter
to Kibana's advanced setting.

[float]
=== Deprecated kibana.yml setting `xpack.monitoring.node_resolver` has been removed
*Details:* This setting has been deprecated since 5.6, when it was explicitly recommended to use `uuid` as its value.

*Impact:* This setting is no longer necessary. If you enable {monitoring} across the Elastic Stack, a monitoring agent runs
on each Elasticsearch node, Logstash node, Kibana instance, and Beat to collect and index metrics. Each node and instance is
considered unique based on its persistent UUID, which is written to the path.data directory when the node or instance starts.

[float]
=== Deprecated API `/shorten` has been removed
*Details:* The `/shorten` API has been deprecated since 6.5, when it was replaced by the `/api/shorten_url` API.

*Impact:* The '/shorten' API has been removed. Use the '/api/shorten_url' API instead.

[float]
=== Deprecated kibana.yml setting logging.useUTC has been replaced with logging.timezone
*Details:* Any timezone can now be specified by canonical id.

*Impact:* The logging.useUTC flag will have to be replaced with a timezone id.  If set to true the id is `UTC`.

[float]
=== kibana.yml setting `elasticsearch.url` sets port based on protocol
*Details:* In prior versions of Kibana, if no port was specified in `elasticsearch.url` a default of 9200 was chosen.
The port is now protocol dependent: https ports will use 443, and http ports will use 80.

*Impact:* If your `elasticsearch.url` was dependent on an unspecified port set to 9200, `:9200` will have to be appended to the url.

[float]
=== kibana.yml setting `server.ssl.supportedProtocols` excludes TLSv1 by default
*Details:* TLSv1 support has been removed by default, it's still possible to opt-in to TLSv1 support by explicitly setting
`server.ssl.supportedProtocols`

*Impact:* Users relying upon TLSv1 will be unable to use Kibana unless `server.ssl.supportedProtocols` is explicitly set.
