Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Troubleshooting / Help

This page is provided for help. It is not normally part of the installation.

When to use this page?

This page is useful if you have deleted an applink between Confluence and Jira, have recreated another link to the same Jira instance, and you want to keep the relationships between Confluence requirements and Jira issues.

Those instructions are valid for Requirement Yogi 2.2.3 and above.


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.


Backup 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 levels.

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

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

Search for Requirement Yogi's integrations with other products
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:

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.

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

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

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:

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

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:

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:

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

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.

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

If so, you're all set.








  • No labels