Changing JIRA Application Title Breaks JIRA Issue Macros in Confluence

Question

I am running Confluence 5.5.4 and JIRA 6.3.1 with a reciprocal application link.  In many of our Confluence pages we use the JIRA Issues macro to link to specific tickets (in Confluence I am using the JIRA Macros add-on version 5.5.4)

I have come across a need to change the Title of our JIRA instance:

JIRA-Administration --> System --> General Configuration

From here I click the Edit Settings button and modify the Application title field to the new name. I go down to the bottom of the page and click Update. The new title is updated successfully in JIRA.

However now when I go back to Confluence the pages using the JIRA Issues macro are unable to display links to the JIRA tickets. Instead I see the following error messag

I figured this might be a problem with the Application Link to JIRA, since the Application title has changed. I removed the reciprocal link from Confluence and JIRA and recreated it. The new link to JIRA now reflects the updated Application title.

Unfortunately this did not change the behavior. All of my JIRA Issues macros are still not rendering correctly and display the same error message of not being able to locate the JIRA server.

If I create a new JIRA Issues macro while in this state, after saving the Confluence page the macro displays correctly and provides the link to the ticket.

When I restored the old JIRA Application title and recreated the reciprocal link, the JIRA Issues macros work as expected again, except for the new one I created while the name was changed.

It appears that the JIRA Issues macros are hard-linked to the Application title for JIRA that existed when they were created.

Has anyone else experienced this problem? Is there any way around this?

Branno · Answer

Stephen, You can use the following SQL query to manually rename all application link references in your Confluence pages: UPDATE bodycontent SET body = Replace(body, 'OLD_LINK_NAME', 'NEW_LINK_NAME') WHERE body LIKE '%OLD_LINK_NAME%'; After this change is made, recreate (or rename the existing) Application Link with the new name. At this point it should work as expected. As this involves directly modifying the database, *ensure you backup the database before making any changes*. Cheers, Stephen Brannen | Confluence Support

Stephen Gurnick · Answer

Hi Giuliano,

Thank you for this detailed response. Fortuantely, I am doing all of this work in my test environment, so this issue has not affected my production systems yet.

The reason this came about is my production environment is running Confluence 4.3.3 and JIRA 5.1. I want to upgrade these to Confluence 5.5.4 and JIRA 6.3.1.  I want to adjust our JIRA application title to reflect a new naming convention we use in our department.

I will try your first suggestion of changing the JIRA application title in this older version first before performing the upgrade to Confluence .

I'll revert my test environment to the older Confluence/JIRA versions, perform the Application title change, and verify the JIRA Issues macros still work. If they do work, I perform the Confluence/JIRA upgrades as well and see if everything still works.

I will report back my findings when this is complete.

My guess is that everything will work fine, but if I ever need to modify the JIRA Application title in the future, I'll be back in this same situation again.

Does Atlassian have an upgrade procedure that performs the necessary steps to adjust the storage format for the Issues macro that avoids this condition?

Thanks again!

Giuliano C. · Answer

Heya Stephen, Before opening a new case with support, this seems to be the situation described in this bug report: https://jira.atlassian.com/browse/CONF-31026 Basically,it's related to the Storage format for the macros and links from JIRA, which have changed with the modification of the instance. For example:

JIRA SERVER NAME issue-key (WE4: Show entries)

Right above, we can see the wrong parameter, from your old JIRA instance, which the name was "SEN JIRA Server". However, if you take a look on this, the only parameter to identify the server is the old Server name. This configuration is a configuration that was applied to older versions of JIRA issues macro.

key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution New Jira serverd24db75a-01fb-308e-a2d2-09352cdfa9d8 issue-key (WE4: Show entries)

Now, with this parameter above, we can see that these are the macros after the re-edit, which started to work. If you take a look, we can see that we have an additional parameter to identify the server, which is the "Server ID" parameter. So, why it identify the JIRA issues and make it work? Because, since the Server name have changed, if it keep searching for the older name, it will never work, but, the server id is still the same. So, the newest versions of Jira issuesmacro are using this additional parameter in order to avoid this unexpected behaviour in servers migration. After re-editing, it start to use the new parameters and use the Server id to identify the same macro from the older server. The older version of the macro doesn't work because it just look for the name, which is not the same anymore. So, we have 4 possible solutions here: Jira Server Name In case of having the server name changed and the only parameters from the older macros (when it have created the issues) would be the name to identify, we lose the older ones. Given that, if you rename the old Jira server back to its original name, and recreate the application link again, all of your macros should work. However, I understand that you have changed the name for the company reasons and it's not feasible to be back using the older name. Replace the value in the database One of the options could be to use the "find and replace" option inside the database, so we would have to change all the older values from the new ones, in order to get all the macros working. However, this procedure is only recommended if you are comfortable to run these kind of queries in order to update the values inside your database. Find this in BODYCONTENT: Old server name And replace it with this: key,summary,type,created,updated,due,assignee,reporter,priority,status,resolutionnew server name10350672-f2fb-3d2c-b2f2-0eaf21d970e1 XML Backup: https://confluence.atlassian.com/display/DOC/Site+Backup+and+Restore You can create a full XML backup of Confluence, and find and replace the values above in the 'entities.xml' file, then reimport the backup. It's very important to do this on a test site first, in case anything goes wrong. If everything goes smoothly on the test instance and the problem is resolved, feel free to do this on the live instance. And for the last option, we know that manually re-editing the macro will make it work again.