If your objects store any links to other objects (with an object type/ID), you need to take specific steps to ensure that these links continue functioning after the 8.0 upgrade.

⚠️ This step must be completed no later than the 7.16 release. ⚠️

If you answered "Yes" to Question 1, you need to make sure that your object links are only stored in the root-level references field. When a given object’s ID is changed, this field will be updated accordingly for other objects.

The image below shows two different examples of object links from a "case" object to an "action" object. The top shows the incorrect way to link to another object, and the bottom shows the correct way.

If your objects do not use the root-level references field, you’ll need to add a migration before the 8.0 release to fix that. Here’s a migration function for the example above:

function migrateCaseToV716(
  doc: SavedObjectUnsanitizedDoc<{ connector: { type: string; id: string } }>
): SavedObjectSanitizedDoc<unknown> {
  const {
    connector: { type: connectorType, id: connectorId, ...otherConnectorAttrs },
  } = doc.attributes;
  const { references = [] } = doc;
  return {
    ...doc,
    attributes: {
      ...doc.attributes,
      connector: otherConnectorAttrs,
    },
    references: [...references, { type: connectorType, id: connectorId, name: 'connector' }],
  };
}

...

// Use this migration function where the "case" object type is registered
migrations: {
  '7.16.0': migrateCaseToV716,
},

A deep link is a URL to a page that shows a specific object. End-users may bookmark these URLs or schedule reports with them, so it is critical to ensure that these URLs continue working. The image below shows an example of a deep link to a Canvas workpad object:

Note that some URLs may contain deep links to multiple objects, for example, a Dashboard and a filter for an Index Pattern.

⚠️ This step will preferably be completed in the 7.16 release; it must be completed no later than the 8.0 release. ⚠️

If you answered "Yes" to Question 2, you need to make sure that when you use the SavedObjectsClient to fetch an object using its ID, you use a different API to do so. The existing get() function will only find an object using its current ID. To make sure your existing deep link URLs don’t break, you should use the new resolve() function; this attempts to find an object using its old ID and its current ID.

In a nutshell, if your deep link page had something like this before:

const savedObject = savedObjectsClient.get(objType, objId);

You’ll need to change it to this:

const resolveResult = savedObjectsClient.resolve(objType, objId);
const savedObject = resolveResult.saved_object;

The SavedObjectsResolveResponse interface has four fields, summarized below:

The SavedObjectsClient is available both on the server-side and the client-side. You may be fetching the object on the server-side via a custom HTTP route, or you may be fetching it on the client-side directly. Either way, the outcome and alias_target_id fields need to be passed to your client-side code, and you should update your UI accordingly in the next step.

⚠️ This step will preferably be completed in the 7.16 release; it must be completed no later than the 8.0 release. ⚠️

The Spaces plugin API exposes React components and functions that you should use to render your UI in a consistent manner for end-users. Your UI will need to use the Core HTTP service and the Spaces plugin API to do this.

Your page should change according to the outcome:

⚠️ This step must be completed in the 8.0 release (no earlier and no later). ⚠️

After Step 3 is complete, you can add the code to convert your objects.

When you register your object, you need to change the namespaceType and also add a convertToMultiNamespaceTypeVersion field. This special field will trigger the actual conversion that will take place during the Core migration upgrade process when a user installs the Kibana 8.0 release:

Saved objects can optionally be encrypted by using the Encrypted Saved Objects plugin. Very few object types are encrypted, so most plugin developers will not be affected.

⚠️ This step must be completed in the 8.0 release (no earlier and no later). ⚠️

If you answered "Yes" to Question 3, you need to take additional steps to make sure that your objects can still be decrypted after the conversion process. Encrypted saved objects use some fields as part of "additionally authenticated data" (AAD) to defend against different types of cryptographic attacks. The object ID is part of this AAD, and so it follows that the after the object’s ID is changed, the object will not be able to be decrypted with the standard process.

To mitigate this, you need to add a "no-op" ESO migration that will be applied immediately after the object is converted during the 8.0 upgrade process. This will decrypt the object using its old ID and then re-encrypt it using its new ID:

When you register your object, you need to set the proper namespaceType. If you have an existing object type that is "share-capable", you can simply change it:

If an object is shared to multiple spaces, it cannot be deleted without using the force delete option. You should always be aware when a saved object exists in multiple spaces, and you should warn users in that case.

If your UI allows users to delete your objects, you can define a warning message like this:

const { namespaces, id } = savedObject;
const warningMessage =
  namespaces.length > 1 || namespaces.includes('*') ? (
    <FormattedMessage
      id="myPlugin.deleteObjectWarning"
      defaultMessage="When you delete this object, you remove it from every space it is shared in. You can't undo this action."
    />
  ) : null;

The Data Views page in Stack Management uses a similar approach to show a warning in its delete confirmation modal:

Users will need a way to view what spaces your objects are currently assigned to and share them to additional spaces. You can accomplish this in two ways, and many consumers will want to implement both:

We implemented the share-capable object type as an intermediate step for consumers who currently have isolated objects, but are not yet ready to support fully shareable objects. This is primarily because we want to make sure all object types are converted at the same time in the 8.0 release to minimize confusion and disruption for the end-user experience.

We realize that the conversion process and all that it entails can be a not-insignificant amount of work for some Kibana teams to prepare for by the 8.0 release. As long as an object is made share-capable, that ensures that its ID will be globally unique, so it will be trivial to make that object shareable later on when the time is right.

A developer can easily flip a switch to make a share-capable object into a shareable one, since these are both serialized the same way. However, we envision that each consumer will need to enact their own plan and make additional UI changes when making an object shareable. For example, some users may not have access to the Saved Objects Management page, but we still want those users to be able to see what space(s) their objects exist in and share them to other spaces. Each application should add the appropriate UI controls to handle this.

This is because of how isolated objects are serialized to raw Elasticsearch documents. Each raw document ID today contains its space ID (namespace) as a prefix. When objects are copied or imported to other spaces, they keep the same object ID, they just have a different prefix when they are serialized to Elasticsearch. This has resulted in a situation where many Kibana installations have saved objects in different spaces with the same object ID:

Once an object is converted, we need to remove this prefix. Because of limitations with our migration process, we cannot actively check if this would result in a conflict. Therefore, we decided to pre-emptively regenerate the object ID for every object in a non-Default space to ensure that every object ID becomes globally unique:

As mentioned in Question 2, some URLs may contain multiple object IDs, effectively deep linking to multiple objects. These should be handled on a case-by-case basis at the plugin owner’s discretion. A good rule of thumb is:

Ideally, if a secondary object on a deep link page resolves to an 'aliasMatch' outcome, the consumer should redirect the user to a URL with the new ID and display a toast message. The reason for this is that we don’t want users relying on legacy URL aliases more often than necessary. However, such handling of secondary objects is not considered critical for the 8.0 release.

As depicted above, when an object is converted to become share-capable, if it exists in a non-Default space, its ID gets changed. To preserve its old ID, we also create a special object called a legacy URL alias ("alias" for short); this alias retains the target object’s old ID (sourceId), and it contains a pointer to the target object’s new ID (targetId).

Aliases are meant to be mostly invisible to end-users by design. There is no UI to manage them directly. Our vision is that aliases will be used as a stop-gap to help us through the 8.0 upgrade process, but we will nudge users away from relying on aliases so we can eventually deprecate and remove them.

The resolve() function checks both if an object with the given ID exists, and if an object has an alias with the given ID.

Outcome 1

When you resolve an object with its current ID, the outcome is an 'exactMatch':

This can happen in the Default space and in non-Default spaces.

Outcome 2

When you resolve an object with its old ID (the ID of its alias), the outcome is an 'aliasMatch':

This outcome can only happen in non-Default spaces.

Outcome 3

The third outcome is an edge case that is a combination of the others. If you resolve an object ID and two objects are found — one as an exact match, the other as an alias match — the outcome is a 'conflict':

We actually have controls in place to prevent this scenario from happening when you share, import, or copy objects. However, this scenario could still happen in a few different situations, if objects are created a certain way or if a user tampers with an object’s raw ES document. Since we can’t 100% rule out this scenario, we must handle it gracefully, but we do expect this will be a rare occurrence.

It is important to note that when a 'conflict' occurs, the object that is returned is the "most correct" match — the one with the ID that exactly matches.

Reading through this guide, you may think it is safer or better to use resolve() everywhere instead of get(). Actually, we made an explicit design decision to add a separate resolve() function because we want to limit the affects of and reliance upon legacy URL aliases. To that end, we collect anonymous usage data based on how many times resolve() is used and the different outcomes are encountered. That usage data is less useful is resolve() is used more often than necessary.

Ultimately, resolve() should only be used for data flows that involve a user-controlled deep link to an object. There is no reason to change any other data flows to use resolve().

External plugins (those not shipped with Kibana) can use this guide to convert any isolated objects to become share-capable or fully shareable! If you are an external plugin developer, the steps are the same, but you don’t need to worry about getting anything done before a specific release. The only thing you need to know is that your plugin cannot convert your objects until the 8.0 release.

Refer to Saved Object IDs documentation for more details how users should expect to be impacted.