Known Limitations

Non-supported fields when creating Collaboration Links on a ELM Application.

If your company use an Internet browser other than Microsoft Internet Explorer, the only field that is not supported is Work Log. If, on the other hand, IE is a must for your company, extra unsupported fields will depend on the Jira and ELM versions used, see "Jira 8 and Internet Explorer 11" topic below.

Jira 8 and Internet Explorer 11

Starting Jira 8 some javascript libraries were updated and they are no longer supported with the IE compatibility mode used by ELM applications.

If your ELM environment is before 6.0.6.1, these are the fields not supported in Jira 8.x.x and IE11 (in the Collaboration Links creation dialog):

If your ELM environment is 6.0.6.1, the only component that does not work is Calendar picker (for all date/time fields).

Jira 7 and collaborationLinks() function

There is a known limitation for Jira 7 of not having more than 65000 issues matching a condition in a function. If, when using the collaborationLinks() function, the expected results are greater than 65000, the message "An unknown error occurred while trying to perform a search." will be displayed.

Fully Qualified Domain Names of Jira and OSLC Remote Application servers

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.

ETM Test Plans linking with Global Configurations

IBM Engineering Test Management (ETM) 6.0.6 and 6.0.5 have a bug when linking a Test Plan with an existing Quality Task using a Global Configuration. In this case, the checkbox used in the Selection Dialog for filtering the issues configured to work with the current configuration is not displayed; meaning users can select issues possibly configured to work with other configurations and resulting in a wrong linking. This problem is solved starting ETM 6.0.6.1.

IBM Rhapsody Model Manager and Change Sets

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.

IBM Engineering Requirements Management DOORS Family with Global Configurations

IBM Engineering Requirements Management DOORS Family 9.7.2 introduces support for linking in the context of a Global Configuration. OSLC Connect for Jira supports linking to DOORS modules with enabled Global Configurations, but no backlink will visible from DOORS to Jira. This is because DOORS is not aligned with the regular behavior in this scenario, where requirement incoming links are supposed to be discovered on demand depending on the selected configuration.

Another point to comment in this context is a weird message displayed by DOORS when trying to link artifacts mixing configuration contexts. When a Global Configuration is set to work on a Jira issue and the target DOORS module is not GC enabled, the error message returned by DOORS is CRCRW5038E An unexpected error occurred during the operation. As part of its policy, OSLC Connect for Jira displays messages sent by remote OSLC application as is, without modifying them.

IBM Engineering Requirements Management DOORS Family and Jira 8.13 (or higher)

Starting Jira 8.6, Atlassian retired support for Internet Explorer. Starting with Jira 8.13, it is verified in practice that Jira becomes no longer usable in Internet Explorer. Since DOORS Client uses an embedded Internet Explorer browser to open web pages of remote applications, DOORS Client is not able to connect/work with Jira 8.13 and higher. DOORS users are highly recommended to stick to Jira 8.5 at maximum.

Link Appearance of IBM Engineering Requirements Management DOORS Family requirements

By default, no priority or status properties are part of the DOORS Family requirements. They can be defined, however, as custom properties to be displayed along with the icon and title of the remote artifact. This will work as far as they are defined as regular text properties but won't work if they are defined as enumeration properties. In other words, if the data type chosen to create these properties is an enumeration, OSLC Connect for Jira is unable to resolve the property value because DOORS Family is not exposing the enumeration definition through the OSLC API.

Large previews not supported on IBM Engineering Requirements Management DOORS Family requirements

When a DOORS requirement is linked to a Jira issue and its preview is requested (using the DOORS client), a small preview is displayed first in a pop-up window. By clicking on the Details >> link (at then bottom of the pop-up window), a larger preview should be displayed. However, if the original small preview is larger than the area designated by DOORS to render it, the actual large preview won't be accessible and the message "The webpage cannot be displayed" is showed instead. This is DOORS bug affecting all other OSLC compliant applications.

Multiple issues selection from Siemens Polarion

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.

No support for traffic distribution or traffic shaping

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:

Since OSLC Connect for Jira uses OAuth to authenticate the communication between Jira and external applications, and part of the authentication dance involves the Jira login page, all REST traffic of OSLC Connect for Jira must be served by the standard nodes (as Jira internal requests require).

Wrong selection dialog in IBM Engineering Systems Design Rhapsody – Model Manager (iFix008)

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.

Issue cloning does not create backlinks in the remote application

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.