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 20 Next »

  • The applinkId will change, just on the side where you recreated it (Jira’s applink in Confluence will have a new ID, but Confluence’s link in Jira can remain the same in some situations),

  • We reference this applinkId everywhere in our data, because it uniquely identifies a Jira instance when there are two of them, so it is very important to keep it aligned with the true applinkId,

  • In Confluence, all links to Jira issues are identified by { applinkId, issueKey }.

  • In Jira, all links to requirements are stored as { applinkId, spaceKey, key, baseline (nullable) }.

  • In both software, the queue messages are targetted at one applinkId, so, if this ID changes, you need to update it.

The advice below only stands when data remains on the same instance. If you are moving/copying data, for example from a local Confluence to a global Confluence, then please rather look at our backup/restore/import/export tool documented here:

Import/export of Requirement Yogi data to a Confluence or Jira instance.

In Confluence, if an applink has changed, we have a wizard:

  • Go to Requirement Yogi administration → tab Integations → Click on the invalid applink,

  • Click “Fix applink”,

  • A wizard will suggest to reassign all records to another ID. You can also entirely delete the records associated to an applink.

In Jira, there is no wizard.

  • Go to the database and edit it in SQL,

  • WARNING There are risks of data loss when editing data in SQL. Please discuss with your system administrator and ensure you have a way to easily restore data if it is broken.

  • Edit the table AO_42D05A_DBREMOTEREQUIREMENT, the column APPLINK, search for all references to the old applinkId and update them to the new applinkId.

See Database schema.

  • No labels