With IBM Engineering Lifecycle Management (ELM) 7.0.2, the way backlinks are discovered in ELM applications has changed.
Previously, it was enough for Jira [1] to associate a project version with a Global Configuration (GC) to allow ELM Configuration-Management-enabled applications to discover backlinks [2]. Now, not only the Jira version needs to be associated (linked) with the GC, but this latter must also be linked with the Jira version... in other words, a double link is required.
Since the first OSLC Connect For Jira version (2.6.0) that supported linking with ELM 7.0.2 applications,
this double link can be managed automatically by Jira [1]. What this means is that you don't need to bother going to
IBM Global Configuration Management (GCM) to create the backlink. As long as the GCM user who logged in,
during the GCM authentication process comes with the right GCM permission/role
(Configuration Lead or Administrator), Jira will create/remove the backlink for you at the time of creating/removing the association.
If the GCM user you connect with misses the roles mentioned above, you will have to ask to the appropriate GCM user
to manage the backlink each time you create/modify/delete an association [3]. In this scenario, during the association/dissociation of a GC, a
Failed to add the backlink or Failed to remove the backlink dialog will appear respectively [4]. There, the cause of the problem will be explained
(the missing permission) and you will have to click on the Save Locally or Remove Locally button (respectively again) to manage the link only
on the Jira side. After this, do not forget to notify to the proper GCM user to take care of managing the corresponding backlink.
Remember, no GCM backlinks to Jira versions means no ELM backlinks to Jira issues.
Saving an association without creating the backlink is only one way to have inconsistent associations. The second common case is when migrating from ELM 7.0.1 to ELM 7.0.2. [5] But whatever the cause, OSLC Connect For Jira lets users know whether some version associations require repairing. There are actually four ways to figure it out, but what all of them have in common is that all they require the GCM authentication process to be completed in the first place... which you can do by either: [6]
Log in button located inside the associations table.Log in hyperlink within the tooltip.Once the GCM authentication process is completed, the four ways to figure out whether repairing is required are:
... button above the associations table is blue.Repair is required. below.Actions menu includes an extra Repair option.Validate GCM Links... button displays a list of all inconsistent associations (for a given GC friend) [7].All methods above but the last one depend on the status of the associations currently being displayed on the page... in other words, they are useless to identify the status of non-visible/filtered versions (a filter can be applied on the page resulting in only correctly configured versions being visible, while there could be yet non-visible/matching versions requiring repairing). If you want to be sure that no repairing is required at all, opt for the last option [8].
Now that you have learned how to identify inconsistent associations, it's time to learn how to repair them... but remember, your GCM user
must have either the Configuration Lead or Administrator role; otherwise the process will fail because of the missing permission.
Once the inconsistent association is identified:
Actions column (on the tree dots icon).Repair option in the opened menu.If everything went OK, a success message will indicate that both resources are now aligned; otherwise the proper error message will be displayed.
... button and select the Validate GCM Links... action.Friend Application combo [9].Repair X version(s) button at the bottom of the dialog.If everything went OK, all statuses will be changed to SYNCHRONIZED and you're free to close the dialog;
otherwise, the associations having problems will be sorted first and you can know the actual problem by hovering the FAILED status [10].
At this point, you can retry all failed associations, by clicking the Retry repairing X version(s) button [11], or close the dialog by clicking the Close button.
After a repair is performed, the legend repair is required. is removed from the repaired associations,
the icon is also updated to show the actual GC icon, and the Repair option is removed from the corresponding Actions menus.
Finally, it's been implied that whenever a Jira association is removed, the GC backlink should also be removed (to keep consistency), and actually,
this is what is done automatically by Jira [1] in regular conditions. However, since the possibility of not having the
required permission/role exists, a checkbox has been added, on the Confirm delete (association) dialog, to avoid trying to remove the GC backlink when present and unchecked.
Be aware that, unless your GCM user does not really have the required roles, you should always leave the checkbox checked to also remove the backlink.