Relationships in CMS projects are defined relations between issues and/or between issues and a specific type of item. They must be configured by project and you can define multiple relationship types within a project. This article focuses on relationships between an issue and an item of a specific type.
Whether or not relationship definitions are configured, an issue's relationships to an item(s) are displayed in the Relationships section of the issue editor which is accessible under Projects when an issue is selected (as shown in the example below), but also under Items when selecting an Issue in the Issues view.
When not defined, these relationships are generically referred to as Item references (SID=IR) as seen above.
With defined relationships in use, the relationships are displayed by type. In the below example, there are 3 different types of links between the selected issue and items - there is one generic Item reference (IR) relationship for "Adaptive cruise control", and three "Requested" requirements, and one "Implemented" requirement. The later two relationship types are custom configured.
As shown above, when it comes to defining relationships or not, you are not limited to one or the other. You can use both custom defined and the generic Item references within a project.
Why Define Relationships?
There are a couple of reasons why you may want to define issue-item relationships. One reason is to clarify the relationship in some way to differentiate it from other types of relationship links. For example, when adding references to requirements that are to be implemented, you may want to use a relationship called "Requested" at first. Then, add relationships of a type called "Implemented" to indicate which of the "Requested" items are implemented.
Relationships can also be used to allow a specific issue type to "float" from one version of an item to the next consecutive version. If you do not use floating, when an item is released and a new version is created, the issues linked to the released version do not "move forward" to the new version. Issues are not versioned. This is the typical use case since the assumption is that when an item is released, all linked issues have been addressed/completed. If you do want the issues to move forward, then you can set up Issue Types in projects to use a relationship type with the floating option enabled which will result in ALL issues - both opened and closed - of that issue type moving forward to the new item version. The link to the previous version of the item is removed. You can then, of course, remove any issues, as needed, on the new version.
What's Next?
See How to Define a Relationship Between Issues and Items or How to Define a Relationship Between Issues.