Given the complexity of some products, some applications have implemented what is called Configuration Management. When enabled, this feature allows to define different versions of a given artifact and group them in components. Let's say a company wants to create a plane, the complexity would suggest us to split the design, and process in general, in components: the cabin, the wings, etc. Now, the design requirements for such plane to fly on America may be different from those in Europe; by having different versions of the same components (and the artifacts on them) engineers could achieve all this work easier: one version for America, one for Europe.
A configuration is, in this context, a version of a component: as many different component versions a team need to work with, as many configurations they need to create. All this is good up to one wonder what configuration on RM application should work with what configuration of QM application? In a collaborative environment, different applications care about different parts of the making process and, in a Configuration-Management-enabled environment, it is important to establish a relationship between configurations (from different applications) that work together, here is where the concept of Global Configuration comes in. A Global Configuration (GC) is a configuration where the artifacts are also configurations... but configurations from different applications (RM, QM, etc) that work together. In other words, the global configuration is the mean to define which local configurations work together.
In Jira, it does not make sense to have different versions of an issue , this makes impossible to define a local configuration which could become part
of a GC, but OSLC Connect for Jira makes possible to create Collaboration Links to OSLC-enabled applications that do.
This is done by making use of the Jira Versions and the fields
Affects Version/s and
whose value can be mapped to a GC through a Collaboration Link type. By having this mapping, and in other words, a Jira issue can be linked to remote versioned artifacts,
depending on the GC mapped by the Jira Version set on the
Affects Version/s or
Fix Version/s field; the actual field used to resolve the GC
depends on the Collaboration Link type the user is creating. Having said that, to enable this versioned linking capability you need to care of :
If you don't apply these configurations, Jira users won't be able to create outgoing links to OSLC Remote Applications with Configuration Management enabled. By applying them, Jira users will still be able to create outgoing links to OSLC Remote Applications with Configuration Management disabled.