Breaking changes in 7.8
editBreaking changes in 7.8
editThis page discusses the breaking changes that you need to be aware of when migrating your application to Kibana 7.8.
Breaking changes for users
editMetrics alerts action messaging refactored to report on the no data state
editDetails
Metrics alerts no longer expose context.valueOf, context.metricOf, or
context.thresholdOf to action messages. These variables are replaced
by context.reason. This variable explains the reason that the alert
fired and automatically includes the metric, threshold, and current value of
all configured conditions.
Impact
Alerts configured in 7.7 still function as normal,
but their action messages might no longer provide useful information and
must be reconfigured. The new default action message will show an example
of how to use context.reason.
via #64365
Panels removed from the URL in dashboard view mode
editDetails
In dashboard in view mode, .panels are no longer synced with the URL.
Impact
This fixes the Back button when navigating between dashboards using drilldowns.
via #62415
Breaking changes for plugin developers
editThe actions API endpoint changed
The following action plugin REST APIs changed so that they are consistent with the Kibana styleguide.
-
GET /api/action/_getAll→GET /api/actions -
GET /api/action/types→GET /api/actions/list_action_types -
POST /api/action→POST /api/actions/action -
GET /api/action/{id}→GET /api/actions/action/{id} -
PUT /api/action/{id}→PUT /api/actions/action/{id} -
DELETE /api/action/{id}→DELETE /api/actions/action/{id} -
POST /api/action/{id}/_execute→POST /api/actions/action/{id}/_execute
via #65936
Canvas applications now run on the new Kibana platform
Any existing user-created plugins that extend Canvas functionality must also move to the Kibana Platform to continue extending Canvas.
via #64831
The filter function uses filterType instead of type
If you used the type argument of the filter function, you now
must use filterType instead.
Old code:
filter type={...} | ...
New code:
filter filterType={...} | ...
The type field is used internally by the expression interpreter to
discriminate between the different values it passes between functions.
The filter function was the only function that exposed this field to users.
After this change, all expression values will consistently use type to determine a type of expression value.
via #64215
Calling navigateToApp to a legacy app redirects to full path
Calling core.application.navigateToApp to a legacy
application now retains the path specified.
via #65112
The legacy aggs APIs were removed
The following legacy aggs APIs from the data plugin search service
have been removed because they are no longer in use:
data.search.__LEGACY.AggConfig; data.search.__LEGACY.AggType; data.search.__LEGACY.aggTypeFieldFilters; data.search.__LEGACY.FieldParamType; data.search.__LEGACY.MetricAggType; data.search.__LEGACY.parentPipelineAggHelper; data.search.__LEGACY.siblingPipelineAggHelper;
Additionally, the following unused static exports have been removed:
AggTypeFieldFilters, AggTypeFilters, IAggGroupNames, // renamed to AggGroupName DateRangeKey, IpRangeKey, OptionedParamEditorProps, // moved to vis_default_editor search.aggs.AggConfigs; search.aggs.aggGroupNamesMap, // renamed to AggGroupLabels search.aggs.aggTypeFilters, search.aggs.convertDateRangeToString, search.aggs.convertIPRangeToString,
via #64719
Applications are now allowed to define and update a defaultPath
Kibana platform applications can now define and update the defaultPath
to use when navigating to them from another application or from the navigation bar.
core.application.register({
id: 'my-app',
// ...
defaultPath: '/some-path',
})
const appUpdater = new BehaviorSubject<AppUpdater>(() => ({}));
core.application.register({
id: 'my-app',
// ...
updater$: appUpdater,
})
// later
appUpdater.next(() => ({ defaultPath: '/some-updated-path' }));
via #64498
Static assets are now served under a release-specific URL
Kibana static assets are now served under a release-specific URL
with long-term caching headers Cache-Control: max-age=31536000.
Before:
http://localhost:5601/bundles/plugin/dashboard/dashboard.plugin.js
After:
http://localhost:5601/bundles/8467/plugin/dashboard/dashboard.plugin.js
via #64414
Example plugins are now allowed in X-Pack
Kibana developers can now create example plugins in
X-Pack—create your plugin in /x-pack/examples folder and start Kibana with:
yarn start --run-examples
via #63823
action.getHref() has improvements for drilldowns
getHref on Action interfaces in the uiActions plugin is now async.
getHref is now used only to support right click behavior.
execute() takes control on regular click.
via #63228
State syncing utils now support ScopedHistory
State syncing utils now seamlessly support the platform’s ScopedHistory.
via #62761
Configuration properties were removed from TSVB
When the TSVB visualization was added to Kibana,
two configuration properties were declared: chartResolution and minimumBucketSize.
No one used these properties, and
an implementation has not been added.
The chartResolution and minimumBucketSize are now marked as deprecated configuration
properties for TSVB.
via #62543
The HttpResources service is available for responding to requests
If your server-side plugin needs to respond to an incoming request with the
HTML page bootstrapping Kibana client app, a custom HTML page, or a custom JS script,
you can use the HttpResources service.
httpResources.register({ path: 'my_app', validate: false }, (context, req, res) =>
res.renderCoreApp()
);
httpResources.register({ path: 'my_app/foo', validate: false }, (context, req, res) =>
res.renderHtml({ body: '<html><p>Hi</p></html>' })
);
httpResources.register({ path: 'my_app/bar', validate: false }, (context, req, res) =>
res.renderJs({ body: 'alert(...);'})
);
via #61797
The legacy embeddable_api plugin has been removed
The legacy embeddable_api plugin in src/legacy/core_plugins/embeddable_api
has been removed in favor of the embeddable plugin in the new Kibana Platform.
If you used the embeddable_api in 7.7, you already used the new
embeddable plugin API, which was re-exported from the legacy platform as a convenience.
As of 7.8, you must update your imports to pull everything from the new location:
// for types & static imports
- import { ViewMode } from '../../../src/legacy/core_plugins/embeddable_api/public/np_ready/public';
+ import { ViewMode } from '../../../src/plugins/embeddable/public';
// for runtime APIs in legacy platform plugins
- import { start } from '../../../src/legacy/core_plugins/embeddable_api/public/np_ready/public/legacy';
+ import { npStart } from 'ui/new_platform';
+ const { embeddable } = npStart.plugins;
// for runtime APIs in new platform plugins
- import { start } from '../../../src/legacy/core_plugins/embeddable_api/public/np_ready/public/legacy';
+ class MyPlugin {
+ start(core, { embeddable }) {
+ ...
+ }
+ }
For plugins using the legacy platform, you also must remove
the embeddable_api from your list of required plugins in your plugin’s index.ts:
export default function MyPlugin(kibana: any) {
const config: Legacy.PluginSpecOptions = {
id: 'my_plugin',
- require: ['kibana', 'elasticsearch', 'embeddable_api'],
+ require: ['kibana', 'elasticsearch'],
...,
};
return new kibana.Plugin(config);
}
For plugins using the new Kibana platform, make sure to list embeddable as
either a required or optional dependency in your kibana.json:
{
"id": "my_plugin",
...,
- "requiredPlugins": [],
+ "requiredPlugins": ["embeddable"],
"optionalPlugins": [],
"server": true,
"ui": true
}
via #61767
src/legacy/server/index_patterns has moved to data plugin
The legacy folder src/legacy/server/index_patterns has been deleted.
The corresponding code was previously moved to the new platform.
For more information on where to locate new platform data services,
refer to the
plugins for shared application services
in src/core/MIGRATION.md.
via #61618
Static assets are now served from the new platform
The Kibana Platform serves plugin static assets from the
my_plugin/public/assets folder. No additional configuration is required.
via #60490
Connectors have been refactored
The API changed to support executor actions. The supported actions are pushToService,
handshake, and getIncident. This change implements only the pushToService action.
The following response fields have changed:
-
incidentIdchanged toid. -
numberchanged totitle.
Create an incident to ServiceNow
When the incidentId attribute is not in actionParams,
the executor will create the incident.
Endpoint: api/action/<action_id>/_execute
Method: POST
Payload
{
"params": {
"action": "pushToService",
"actionParams": {
"caseId": "d4387ac5-0899-4dc2-bbfa-0dd605c934aa",
"title": "A new incident",
"description": "A description",
"comments": [
{
"commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
"version": "WzU3LDFd",
"comment": "A comment"
}
]
}
}
}
Response
{
"status": "ok",
"actionId": "f631be57-0a59-4e28-8833-16fc3b309374",
"data": {
"id": "7d7aad9c072fc0100e48fbbf7c1ed0c2",
"title": "INC0010044",
"pushedDate": "2020-03-10T13:02:59.000Z",
"comments": [
{
"commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
"pushedDate": "2020-03-10T13:03:00.000Z"
}
]
}
}
Update an incident to ServiceNow
When the incidentId attribute is in actionParams,
the executor will update the incident.
Endpoint: api/action/<action_id>/_execute
Method: POST
Payload
{
"params": {
"action": "pushToService",
"actionParmas": {
"caseId": "d4387ac5-0899-4dc2-bbfa-0dd605c934aa",
"incidentId": "7d7aad9c072fc0100e48fbbf7c1ed0c2"
"title": "A new incident",
"description": "A description",
"comments": [
{
"commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
"version": "WzU3LDFd",
"comment": "A comment"
}
]
}
}
}
Response
{
"status": "ok",
"actionId": "f631be57-0a59-4e28-8833-16fc3b309374",
"data": {
"id": "7d7aad9c072fc0100e48fbbf7c1ed0c2",
"title": "INC0010044",
"pushedDate": "2020-03-10T13:02:59.000Z",
"comments": [
{
"commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
"pushedDate": "2020-03-10T13:03:00.000Z"
}
]
}
}
via #63450