Link asset objects to Jira Cloud issues automatically

Summary

After a Data Center → JSM Cloud migration, Assets object keys are reassigned during import, breaking the link between Assets custom fields and the objects they referenced. This article gives automation workarounds to re-link them.

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 matching issues with an invalid object, e.g. customField IN aqlFunction("Key IS EMPTY").

• Lookup Object action — find the imported object, using customField.split(":").last to extract the object ID for matching on Old Key LIKE <id>.

• Edit Issue action — set the Assets custom field from lookupObjects.

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, 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 when moving the data during import.

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

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.

After the rule runs, open a sample migrated issue and confirm that the Assets custom field now resolves to the correct object. Then narrow the JQL and re-run for any that remain empty.

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 finding and replacing 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 the API endpoint Get AQL objects, and then use the Jira edit issue API to update the issue with the object value:

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.