Issue Summary

When Jira Macro Repair (JMR) presents a list with multiple application link names, the ones that were found on the body of Confluence pages, it's possible to map them to the existing ones on the Confluence site. However, there are cases where although the application links found may have different names, they can share the same application ID. When that happens, JMR will map only one of the multiple occurrences that share the same application ID.

This is reproducible on Data Center: (yes)

Steps to Reproduce

There are multiple ways of reproducing this, but we'll list only one here.

1. Create an application link between a Jira and Confluence on-prem, name it, for example, "App link to JIRA".
2. Create some Jira macros on some Confluence pages. This will be created using the "App link to JIRA" app link.
3. Delete that application link and recreate it using a different name, for example, "App link to Jira".
4. Flush the Application Links cache or restart Confluence
5. Create some Jira macros on some Confluence pages. This will be created using the "App link to Jira" app link.
6. Migrate both Jira and Confluence to the cloud
7. Execute JMR, and have the following mapping, for example,
   • "App link to JIRA" -> "System JIRA"
   • "App link to Jira" -> "System JIRA"

Note that the application link ID is generated from the products' manifest files (it's dependent on their IDs). That's why, after recreating the app link, the ID will still be the same—the information on the manifest file won't change.

Expected Results

All occurrances from "App link to JIRA" and "App link to Jira" will be mapped to "System JIRA".

Actual Results

Only one of the occurrances will be mapped to "System JIRA". The one that gets picked up can be determined by a number of factors.
JMR fails silently and presents a message that the Jira macros were fixed.

Workaround

Currently, there is no known workaround for this behavior. A workaround will be added here when available.
Contact Migrations support via our support portal.