The Jira Work Log field is not supported.
If Jira and the OSLC Remote Application share the same fully qualified domain name (FQDN) and port, every time a pop-up window is open to display Jira content,
Jira assumes the parent window contains also Jira content and tries to reuse some code from there. As OSLC Connect For Jira
relies on pop-up windows to display Jira content on the OSLC Remote Application, Jira assumption fails and code gets broken when trying to use
the selection or creation dialog; this latter for example will not display properly the issue type and other pickers when rendered. To avoid this problem, make sure the FQDN or the port number of these two servers is different.
E.g. if your Jira is available at http://servers.example.com:443/jira/, then you cannot have the OSLC Remote Application at http://servers.example.com:443/remote/ but have to prefer using a different port,
let's consider 8443: http://servers.example.com:8443/remote/. If your Jira is available at http://jira-server.example.com:443/, then your OSLC Remote Application setup can be http://remote-server.example.com:443/ because the FQDN is different.
Note: this limitation prevents (partially) linking a Jira instance with itself (only linking by drag and drop is functional). OSLC Connect For Jira is fully functional for linking two (or more) Jira instances as long as their FQDN is different.
When creating an external link in IBM Rhapsody Model Manager (RMM), it is possible to associate a change request (Jira issue) to it; the result is a Change Set being created and linked to the Jira issue which should be also linked back to the Change Set, however, this is not the case. Due to an RMM limitation, the backlink on Jira is not created and only the link from RMM to Jira is created.
Siemens Polarion does not support multiple submit of issues for linking. The OSLC Connect for Jira selection dialog supports selecting more than one issue for linking at the same time; however, given a Polarion's limitation, only the first element on the selected issues will be linked.
Traffic shaping is a popular technique applied on a load balancer to forward specific traffic type (typically REST traffic) to a dedicated node, in a cluster, and leave the other nodes free to serve regular traffic. Jira supports traffic shaping, as long as two basic rules are followed:
A bug identified in IBM Engineering Systems Design Rhapsody – Model Manager (iFix008) causes that, when opening the Issues selection dialog for linking, a wrong Jira Version's picker is open instead. IBM confirmed this bug has a random behavior which means the right selection dialog could be open from time to time. The fix was planned for the 7.0.3 release.
When cloning a Jira issue, the user has the option to clone collaboration links. This will not clone backlinks in the OSLC Remote Application. The backlinks will be visible only if the OSLC Remote Application is Configuration Management enabled. In this case, backlinks are discovered by the remote application rather than being kept internally.
When Global Configurations are in use, and link creation is started from a remote application for a new Jira Issue, the Affects Version/s or Fix Version/s field is prefilled
with a Version associated with the Global Configuration, if any. This action is required to properly link the Jira Issue back with the remote artifact; however, the corresponding field must be part of the
Create Issue Screen, or failing that, the Edit/View Screen of the underlying project. If this condition is not met, the prefilled value will be ignored by the Jira engine at the moment
of the Issue creation; causing the backlink created in Jira to refer to a different artifact in the remote application. If Global Configurations are going to be used, make sure these fields are part of any of the mentioned screens.
If the Issue Links field is present in the Creation Dialog screen, switching the issue type causes any data entered in this field to get lost. This is a known behavior of Jira itself and occurs only when
the issue type is changed; data is not lost when the issue is created.
When Quality Management resources exist in a Configuration Management enabled project, the OSLC specification mandates that multiple versions of the same Issue may exists along different local components and configurations.
Jira architecture, however, does not support this: there is no way to have different versions of the same Issue and the concepts of local configuration and components do not exist. To address this, OSLC Connect for Jira
emulates these concepts/behaviors as follows: each Configuration Management enabled project contains a single component with the same name of the project; the project Versions become local configurations (Streams if they are not yet released or Baselines if they are);
and Jira Issues mapped to Quality Management resource types become the unique versioned artifact of themselves. In other words, there is a single version of an Issue Test Case, but this single version can be part of multiple local configurations: it will
be part of each Version (Configuration) assigned to it in either the Affects Version or Fix Version field (the actual field to use depends on the resource type, see the administration guide for details).
When Quality Management resources exist in a Configuration Management enabled project, Change Management links to remote applications cannot be displayed. Change Management links can be created from Jira or the remote application in this case but they will be visible only in the remote Change Management application, not in the Jira Quality Management issue types. The link discovery required for this functionality is not implemented.