Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Warning
titleBackup your database before proceeding

Please follow Atlassian's instructions about backups before proceeding. Although we, developers, change this data often, a non-experienced user may change the wrong data by mistake, and/or a heavily used application could have cached data at several level.

Prerequisites

Those instructions are valid for Requirement Yogi 2.2.x and 2.3.x.

...

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

In 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).

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

...

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

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

...

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

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

...

Here is the layout of the table:

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.

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

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

Yes, it is not the same as Jira's applink ID on the other side. However, this is much harder to determine. Please derive information by browsing the data returned by the following query:

Code Block
languagesql
SELECT * FROM BANDANA WHERE BANDANAKEY LIKE 'applinks%';

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:

...

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").

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.

Code Block
titleDo NOT do this if you risk having records with the same SPACEKEY, KEY and BASELINE after updating the APPLINK
UPDATE "AO_42D05A_REMOTEREQUIREMENT" SET "APPLINK" = 'your-new-applinkid' WHERE "APPLINK" = 'your-old-applinkid';

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

...