Changing JIRA Application Title Breaks JIRA Issue Macros in Confluence

[Stephen Gurnick]

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]

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, '<ac:parameter ac:name="server">OLD_LINK_NAME</ac:parameter>', '<ac:parameter ac:name="server">NEW_LINK_NAME</ac:parameter>')
WHERE body LIKE '%<ac:parameter ac:name="server">OLD_LINK_NAME</ac:parameter>%';

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

[Branno]

Stephen,

I tested this in Confluence 5.5.3 and JIRA 6.3, as I already have them setup with reciprocal Application Links. I created a JIRA report page in Confluence, as well as a blank page that contained the JIRA Issue Macro.

I changed the name of the JIRA Application Link in Confluence then refreshed the page and the macro still worked.

If you look in the Confluence database and perform this query:

SELECT * FROM bandana WHERE bandanavalue LIKE '%JIRA%';

You will see as you change the name of the Application Link (as long as the name has JIRA in it), the bandanavalue will change to reflect the new name but the bandanakey should not. This is how the macros link back to the right Application Link, using the bandanakey (which is static) and not the bandanavalue (which changes).

Now, while I am not able to replicate this issue I am using Trusted authentication (basic trusted, not OAuth). What kind of authentication are you using? Have you looked into your logs to see if there are any warnings or errors being generated that could assist in diagnosing the issue?

I recommend putting in a support ticket so we can work on this through offical support channels.

Cheers,

Stephen Brannen | Confluence Support

[Stephen Gurnick]

Thank you, Stephen. I'll open a support ticket to work on this.

However to answer your questions, the Atlassian logs in both Confluene and JIRA do not show anything when I go to a page with the broken macros. Using the default logging levels, nothing erroneous is written to the log files.

I am using basic Trusted authentication as well (not OAuth).

For what it's worth, my prior JIRA Application title did not have the word JIRA in it. But I am attempting to change it to a phrase that does have the word JIRA. When I run your SQL query on my Confluence database, three rows are returned one of which contains my new Application Title with the word JIRA contained in it.

Thank you for your suggestions - I'll see what the support team recommends.

[Giuliano C_]

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:

<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 />

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.

<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 />

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:

<ac:parameter ac:name="server">Old server name</ac:parameter>

And replace it with this:

<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>

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.

[Stephen Gurnick]

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!