After importing a Confluence space, I get JIRA macro errors

Uy Hoang

I am exporting a Confluence space from my installed instance of Confluence (5.5.1) and importing it into my OnDemand instance. Since I am also migrating from JIRA Installed (old) to JIRA OnDemand (new), I edited entities.xml to do a string find and replace of all the URLs from the old JIRA instace to the new JIRA.

I have pages where I have inserted the JIRA issue macro. Instead of displaying the issue number and description, I get this error:

Error rendering macro 'jira' : Unable to locate JIRA server for this macro.

Since I edited the link in entities.xml, clicking on that message will take me to correct issue in the new JIRA. I can go through and fix all these macros by hand, pointing them to the new JIRA but that would be very time consuming. Is there a way to do it during the export/import process?

Giuliano C.

Hey Uy,

It looks like that you are facing a situation described in this bug report https://<span< a="">>jira.atlassian.com/browse/CONF-31026. However, looking through your Storage File and mine Storage file after some modifications, I was able to notice an interesting thing:

{code}
<li><ac:structured-macro ac:name="jira">
<ac:parameter ac:name="server">JIRA SERVER NAME</ac:parameter>
<ac:parameter ac:name="key">issue-key</ac:parameter>
</ac:structured-macro> (WE4: Show entries)<br /><br />
{code}

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.

{code}
<li><ac:structured-macro ac:name="jira">
<ac:parameter ac:name="columns">key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution</ac:parameter>
<ac:parameter ac:name="server">New Jira server</ac:parameter
><ac:parameter ac:name="serverId">d24db75a-01fb-308e-a2d2-09352cdfa9d8</ac:parameter>
<ac:parameter ac:name="key">issue-key</ac:parameter>
</ac:structured-macro> (WE4: Show entries)<br /><br />
{code}

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.

That's the main reason for us not being able to reproduce the same behaviour as you - our JIRA issues macro was the newest version, which has the Server ID parameter, so when we changed the server name, it looked up on the ServerID instead. Yours were mostly created with a version that didn't contain the Server ID, so when the name of the JIRA server changed, the macros can no longer find it.

So, we have 4 possible solutions here:

Jira Server Name

Since 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. That being the case, 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:
{code}
<ac:parameter ac:name="server">Old server name</ac:parameter>
{code}

And replace it with this:
{code}
<ac:parameter ac:name="columns">key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution</ac:parameter><ac:parameter ac:name="server">new server name</ac:parameter><ac:parameter ac:name="serverId">10350672-f2fb-3d2c-b2f2-0eaf21d970e1</ac:parameter>
{code}

h4.[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. However, it's not an feasible option, as we have discussed before.

Hope it helps ya!

Cheers,

Giu