I have had a stupendously shitty experience trying to import OnDemand data into local JIRA and Confluences. In this bug report I've documented the problems, what I think OnDemand developers could do to fix them in bold, and how I worked around them.
The problem is that after importing a Confluence Could export into Confluence (5.0.2), you'll find all jiraissues macros broken (note: I had previously migrated JIRA data to its new home):
and a cryptic error in the logs:
With a bit of thinking one might figure out the error: the applinks are all broken, as is to be expected with the change of host.
So off we go to the applinks page:
Applinks are not editable, because they are marked 'system'.
Suggested fix 2: The Confluence Cloud exporter should remove the 'system' flag from the applink, so mortals can edit them
The 'system' flag can be removed manually in the database:
Now I can edit the applink:
And then my problems really began.
For a start, the applink URL isn't editable:
(Questionable design decision here: sure, changing the URL to a different JIRA would break everything, but most times it's the same JIRA, just under a different URL.)
So anyway, let's edit the URL in the database, first by finding the applink ID, finding the applink's properties, then changing the URLs:
(and whatever you do, don't change the applink's title-
even though it contains an incorrect URL too-the title is embedded in hundreds of Confluence page jiraissues macros. That is a job for bulk-rewriting.)
After a Confluence restart, the applink appears with the correct link.
Switching to the 'Outgoing Authentication' tab, it claims to be in Status: Configured. Just to be sure let's disable and re-enable it. Clicking 'Disable' is easy enough, but then:
Where is the 'Enable' link??
This is a UI bug (affects Firefox 16.0.1, Chrome 26.0.1410.63) - the link is actually there, and can be seen by clicking on the last form element (the timeout field) and pressing tab:
So we click 'Enable', and:
"But hang on", I hear you say, "why are you trying to fix this obviously borked applink? Just delete it and start again". No such luck:
"Okay, what about that 'Upgrade application link' button?" It dies with the JS equivalent of a NullPointerException:
So we're left with an applink we can't fix and can't delete.
Fortunately, Googling the exception brings up this KB article, which points to the cause: the #@#%! Confluence Cloud exporter has erased all the KEYSTORE records, which trustedapps depends on:
The KB article points to CONF-11074, which helpfully includes a JSP to recreate the KEYSTORE.
So I run the JSP, which populates my KEYSTORE table with a public/private keypair, and now - hurrah - I can enable Outgoing Authentication. After a restart, the jiraissues macros that rely on the applink work too.
Don't just leave them blank when doing so results in a broken, undeletable, unfixable applink. Create a new unique keypair using the code from the
CONF-11074 JSP and put the keys in KEYSTORE.
Thank you for reading.