Relationship Groups
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 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 Group Type | Purpose |
| Bi-Level | This is a simple relationship group where a single issue acts as a parent issue to any number of child issues. This has largely been superseded by the One-to-Many type, but its use will be continued for backwards compatibility. If you are designing a new ExtraView application, or adding relationship groups to an existing installation, it is recommended that you do not use the bi-level groups. To continue using this type of relationship group and to ensure that bi-level groups are updated, the behavior setting named RG_UPDATE_BILEVEL_ONLY should be set to a value of YES. To remove the ability to create new relationship groups with the type of bi-level, set the behavior setting named ALLOW_BILEVEL_GROUPS to a value of NO. Bi-level relationship groups will not operate correctly unless this setting has a value of YES. |
| One-to-Many | This type also has a single parent issue with multiple child issues, but with some differences and enhancements from the bi-level type of group. This type of relationship group should be used in preference to the bi-level group type for all new applications. If you want the capability to update all related issues when performing the update of an issue, you must set the behavior setting named RG_UPDATE_BILEVEL_ONLY to NO. |
| One-to-Many Cascade | This type is similar to the One-to-Many relationship group type. The difference is that when a user deletes an issue which is the parent of one or more child issues, then the child issues are also deleted, as opposed to leaving orphaned child issues in the database, once the parent is deleted. |
| Many-to-Many | In the many-to-many relationship group type, an issue can belong to more than one relationship group, and many issues can be connected in many ways. . If you want the capability to update all related issues when performing the update of an issue, you must set the behavior setting named RG_UPDATE_BILEVEL_ONLY to NO. |
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.
Let us look at some use cases for relationship groups, to see how they can be formed for different purposes.
