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.