Requirement Yogi relies on "Application links" to communicate between Confluence and Jira.

• An applink exists with a given UUID from Jira to Confluence,
• An applink exists with another UUID from Confluence to Jira,

If you change the applink keys, all relations are broken. Your Jira issues won't be updated with the latest requirement text; the requirements won't list the related issues; and the queue of messages between Confluence and Jira will fill up. To fix those, we've detailed the following steps.

Prerequisites

Those instructions are valid for Requirement Yogi 2.2.x to 2.6.x.

The new Applink exists and is connected, the old Applink was removed.

You've added a username for the new Applink in the Requirement Yogi administration in Confluence, tab "Integrations".

In Confluence

The Confluence part has now been replaced with a wizard, in 2.4.8. In the Requirement Yogi administration, click "Integrations", select the Jira instance that is disconnected, and there is a link "Fix applink" at the bottom.

...

Shut down Confluence

We don't know what is the impact of performing these changes while Confluence is running, so by default we recommend shutting down Confluence. If you don't follow this recommendation, please at least disable Requirement Yogi temporarily before changing the database. (In development, we've always had success changing values in live, but in development we don't need reliability of data).

Get the old and new Applink ID

SELECT * FROM "AO_32F7CE_AOINTEGRATION" WHERE "SERVICEID" = "APPLINKID";

All the tables of Requirement Yogi in Confluence start with AO_32F7CE.

Note: Depending on your database, the quotes can be:

• No quotes,
• `table`
• 'table'
• "table"
• [table]

Here is the layout of this table:

Image Removed

SERVICEID should be equal to APPLINKID for all links to Jira instances that were created using Atlassian's "Application links" system (the API is designed to support other types of integrations, but we haven't programmed it yet).

Once you've determined what is the old and new "APPLINKID" (as per the table above), proceed to the next steps.

Change AO_32F7CE_AOREQUIREMENT_LINK

This table contains links and relationships between objects, and some of them are the Jira issues. 

Image Removed

In this table, only for records which have an APPLINK equal to the old applink and non-null, please update it to the new applink.

UPDATE "AO_32F7CE_AOREQUIREMENT_LINK" SET "APPLINK" = 'your-new-applinkid' WHERE "APPLINK" = 'your-old-applinkid';

Change AO_32F7CE_AOINTEGRATION_QUEUE

You are going to move any message that was initially destined to the old Jira:

UPDATE "AO_32F7CE_AOINTEGRATION_QUEUE" SET "SERVICEID" = 'your-new-applinkid' WHERE "SERVICEID" = 'your-old-applinkid';

Here is the layout of the table:

Image Removed

If you have Requirement Yogi 2.3

If you have RY 2.3.x in Confluence, then you also need to update the table AO_32F7CE_AOISSUETEMPLATE.

UPDATE "AO_32F7CE_AOISSUETEMPLATE" SET "APPLINKID" = 'your-new-applinkid' WHERE "APPLINKID" = 'your-old-applinkid';

In Jira

Shut down Jira

Same as for Confluence: We recommend shutting down Jira and performing a backup before starting. If you don't, at least disable Requirement Yogi for Jira.

Determine the Applink ID of Confluence

You can easily determine the Appliink ID by going to the Jira administration → Application links → click on "Edit" next to the Confluence link → The ID is in the URL.

To confirm, you can run the following query and check whether the IDs match:

SELECT * FROM BANDANA WHERE BANDANAKEY LIKE 'applinks%';

Change Jira's AO_42D05A_REMOTEREQUIREMENT

Our tables in Jira start with AO_42D05A. We keep a storage of requirement definitions that are linked to issues. Here is a structure of the table:

Image Removed

FIrst, you need to determine whether there are requirements duplicated between the two applinks.

SELECT "APPLINK", COUNT(*) FROM "AO_42D05A_REMOTEREQUIREMENT" GROUP BY "APPLINK"

If this request returned results for both the old and new applink, then it will be more difficult. Please do NOT use the next task ("Move requirements") and proceed to the following one ("Manually merge requirements").

Move requirements to the new applink

If the request above didn't return any result for the new applink, then you can just update all requirements to reassign them to the new applink.

UPDATE "AO_42D05A_REMOTEREQUIREMENT" SET "APPLINK" = 'your-new-applinkid' WHERE "APPLINK" = 'your-old-applinkid';

Or manually merge requirements

If (and only if) you have requirements for both the old and new applink, then you have to manually merge them:

• Find duplicates. The "primary key" of this table is APPLINK, SPACEKEY, KEY and BASELINE. If you exclude the APPLINK and have duplicates, then they need to be merged.
• Reassign their children. Find children in the table AO_42D05A_ISSUELINK (REQUIREMENT_ID = AO_42D05A_REMOTEREQUIREMENT.ID) and reassign them to the correct parent requirement,
• Delete the wrong record in AO_42D05A_REMOTEREQUIREMENT.

Restart Jira and check your work

• Restart the instances, and check Requirement Yogi is enabled in both instances.
• Check in the Requirement Yogi administration in Confluence, tab "Integrations", that the queue has no error,
• Check you can create a link in Jira to a Confluence requirement,
• Check when you update a requirement, that the text is updated in Jira.

...

Until version 3.5.0, it used to be difficult to move requirements from one instance to another. Since then:

• We've made it possible to migrate data within the apps,
• We've also made it possible to export data, then reimport after changing the applink ID.

Please see the history of this page if you have an older version of Requirement Yogi.