Product Documentation

Relationship groups allow the users of ExtraView to associate individual issues with each other. You may want to create relationships between issues for several reasons, for example, because you want to consider them together when making updates, preparing reports, or because you want to implement a workflow which mandates that you update issues as a group, or because you want a workflow where the parent issue cannot be closed until all the child issues are handled.

Relationship groups are configured with a layout type that is then embedded within an add, edit, report layout or another embedded layout. This layout is configured with layout cell attributes to identify the basic characteristics of the related issue display. You might need to provide some business rules to control the interaction of the related issues. For reporting with related issues you will need to define the reporting hierarchy. Examples of relationship groups:

• A project may be composed of many tasks. The project can be stored in an issue, and each of the tasks may be stored in related issues
• A product release may be supported by many individual features. The product release may be stored in an issue while the features may be stored in related issues
• A reported incident may have a number of corrective actions that must be applied. The incident may be stored in a parent issue and the corrective actions may be stored in related issues.

Relationship groups can be built with many different types of behavior. Examples of how to build installations with related issues at their core is described later in this section of this guide. There are several types of inbuilt relationship groups that can be defined:

Relationship groups go beyond the grouping of issues using report filters. For example, it is always straightforward to produce a report that groups issues where there is a common searchable field, such as all the issues that affect a specific product or have the same priority. Relationship groups share a number of common characteristics:

• You can relate different items or issues together. Users achieve this through the add or edit screens. The administrator may also perform this from the Relationship Group Maintenance screen
• When you update a member of a related issue group, you can configure behavior that will optionally allow the user to update all the related members of the group. You can create a layout that contains the fields that may be updated in all issues when one member of the group is updated
• Users may remove items from groups via the add or edit screens. Again, the administrator may also perform this from the Relationship Group Maintenance screen
• You may view all the items in the relationship group, from the add, the edit screen or from reports such as a Quicklist or a Detailed report. From any of these places and with permission, you may drill down and view or edit the issues
• With permission, when you update an issue that is a member of a relationship group you may apply updates to the other members of the group
• When issues are cloned, rules can be used to place these issues in a relationship group.

Relationship Types

Simple Relationship

The simplest relationship may be that you want to connect two issues together, for example because they exhibit similar symptoms, or because they were reported by the same customer. This can be represented by the following diagram:

One-to-Many or Parent-Child Relationship

Typically, a parent – child relationship group will be implemented with the One-to-Many group type. The most common use cases are where you want a single issue to control the behavior of the child issues, for example, several customer-reported issues may not be closed until the engineering issue that controls the fix to the problem has been solved and closed. In this case the engineering issue would be the controlling parent issue.

Sibling Relationships

Sibling relationships link issues at the same level in a hierarchy. Typically sibling issues will have a single parent to which they are linked. Each of the siblings may in turn have child issues. A common use case is where you want to perform an action on the parent issue, when all siblings have a common value in a field and you want to reflect this within the parent issue. For example, you might want to automatically set the status of the STATUS field within a parent issue to Approved when each of the child issues has a radio button that indicates approval of that child issue. A SIBLINGS relationship allows you to compose a rule that would take action on the parent when all the siblings have the same value indicating that approval is given for that individual sibling.

Complex or Arbitrary Relationships

The Many-to-Many relationship group type allows a very flexible structure of relating issues, where you can connect issues in almost any form, and a single issue can be a member of more than one group. The use case here is to allow a very freeform structure where different groups of issues can be connected together. Features exist to allow you to look up and down the structure, to the parent or parents of an issue, to an issue’s children, or even to look beyond the direct relationship and include the related issues to the parents or children of the issue. This is represented by the following diagram:

Security Keys for Relationship Groups

Behavior Settings for Relationship Groups

Data Dictionary Fields for Relationship Groups