Summary

When migrating to JSM Cloud from Server/Datacenter, Object Keys are changed upon Import, causing a disconnect between the Assets Custom Fields & the Asset Objects they need to point to.

This article covers how to fix the values in the Custom Fields so they point to the correct Objects.

Environment

Automation for Jira and JSM Assets

Solution

Workaround 1: Automation to edit the Assets Custom Field

The structure of the Automation Rule would be something along the lines of:

• Trigger: Scheduled > JQL > A query that matches the relevant Issues: customField IN aqlFunction("Key IS EMPTY") - This should target all Issues with a Field of customField that has an invalid Object.
• Action: Lookup Object > Find the imported Assets Object that needs to be entered into the Assets Custom Field on the Issue - customField.split(":").last - This should return the object ID itself, which can be used in Old Key LIKE <id>.
• Action: Edit Issue > Set the Assets Custom Field to the Appropriate Value - lookupObjects - This should return the Keys of the Objects the previous Action found.

The easiest way to find the appropriate value for the Custom Field is to look it up in the original system, then use that information to find it in the cloud Site the Rule is running on.

This can be achieved with a Send Web Request Action, if the original system is available via the Internet. If it is not, then the best way to handle this would be to store the Key value from the original system as an Attribute in the destination Site, which requires prep while moving the data over during import.

Then, this can be used to lookup the new Object using the information in the Assets Custom Field, since it retains the original Object ID (the number portion of the Key, i.e. ABC-123 → 123 is the Object ID).

The data in Assets Custom Fields is formatted as the workspaceid:objectid. Which will be the original system's values. So, these can be used in the Lookup Objects Action to use in the Edit Issue Action in the above example.

Workaround 2: CSV import the Object information

CSV import is an alternative to using Automation. It requires exporting the Issues from the original system, then find→replace the Assets Custom Field values with the corresponding values in the destination Site.

Functionally, this is the same process used in this KB Article: How to import Jira User Attributes to Assets via CSV with either Atlassian Account or Customer IDs where it talks about Google Sheet functions to do the find→replace on the exported Issue Data.

It all starts with creating a CSV of the key pair mapping between the original system & the destination Site using that process.

After the find→replace is complete, such that the Assets Custom Field in the exported Issue Data has been updated, a simple find→replace must be done with the Workspace ID:

• Developer - JSM REST API - Assets Workspace ID - The summary is to go to this URL: https://site.atlassian.net/rest/servicedeskapi/assets/workspace (change <site> to your Site's subdomain) and copy the workspaceId value.

Once both find→replaces have been completed, importing the CSV as mentioned here will complete the process of linking the Issues to their Objects in the destination Site:

• Import data from a CSV file

Workaround 3: Software Scripting

You can create a software script (such as with a scripting language like PHP, Python, etc) to find the new objects using AQL by querying the unique attribute with the help of API endpoint Get AQL objects and then use Jira edit issue API to update the issue with the object value:

{"fields":{"customfield_xxxxx":[{"id":"<WorkspaceID>:<ObjectID>"}]}}

Where customfield_xxxxx is the custom field & its ID, which can be found in the URL while viewing the Custom Field's configuration page in Jira.

Due to the complexity of this option, this article won't be covering that process.