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 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.
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
| Key | Purpose |
| CF_RELATIONSHIP_GROUP_VIEW_ PROBLEM_BUTTON | Controls the appearance of the View button on the Related Issues Screen. Only used for BI-LEVEL relationship groups. |
| PR_ADD_PROBLEM.RELATIONSHIP_GROUP | Controls access to the RELATIONSHIP_GROUP button on the add screen. |
| PR_RESOLUTION.RELATIONSHIP_GROUP | Controls access to the Related Issues (the button beside ID on the Edit screen) for BI-LEVEL groups, and to see the RELATIONSHIP_GROUP field on the edit screen |
| PR_RESOLUTION.RELATIONSHIP_ GRP_ADMIN | Controls the visibility of the Manage Relationship Group button on the edit screen for BI-LEVEL relationship groups. |
| CF_RELATIONSHIP_GROUP | Controls the visibility of the Group Issues button on reports (this is next to the Refresh button at the top and bottom of column, summary, Quicklist and Detailed reports |
Behavior Settings for Relationship Groups
| Key | Purpose |
| CLONE_RELATION_GROUP | Relationship group name for clone relationships. When an issue is cloned it will automatically be placed into the relationship group named in this setting. |
| MORE_HISTORY_NUMBER_ROWS | This setting defines the number of rows of related issues to display, before a more … prompt appears within the history record. This is to prevent the situation where you may have hundreds of related issues, and many updates. In this case, the user would mainly see history of the related issues, as opposed to seeing the history of the issue itself. |
| RELATION_GROUP_DEFAULT | The name of the relationship group that will be used for any issue being placed into a relationship group. This default can be overridden by using a layout cell attribute on the RELATED_ISSUE_DISPLAY, or by using the field RELATIONSHIP_GROUP on the add or edit layout to offer the user a choice of relationship groups |
| RELATIONSHIP_GROUP_EMAIL_LIMIT | When you update the status of an issue within a relationship group, each issue will be subject to the standard notification process. When there are more than RELATIONSHIP_GROUP_EMAIL_LIMIT entries in the group, notification is only made to the users in the parent issue, and a comment is inserted on the issue with this information |
| RELATIONSHIP_GROUP_LIST_UDF | This setting is the name of a user defined field with a display type of list. This UDF is used to maintain a list of the names of relationship group for related issue display. The UDF is maintained by ExtraView as relationship groups are created or deleted. The UDF can also be aliased by other UDF’s to provide an unlimited number of fields that can be used to identify the relationship group names to support multiple related issue displays on a single edit screen. |
| RELATIONSHIP_GROUP_MAX_DISPLAY | Maximum number of issues to display on the relationship group screen. 0 means there is no limit. Note that the administration user defined in ADMIN_OVERRIDE_ROLE will always see all the issues, no matter the value of the setting |
| RELATIONSHIP_LINK_DISPLAY | If the data dictionary entry RELATIONSHIP_GROUP_ LINK is placed on the edit screen layout then either a link or list will appear beside the title. The display of the field is controlled by the behavior setting named RELATIONSHIP_LINK_DISPLAY. This can have a value of either SELECT or LINK. The RELATIONSHIP_GROUP_LINK entry should not be placed on the add screen. If the value is LINK then the field will appear on the edit screen as a link specifying the number of issues in the group. If this link is clicked on, the user is redirected to the Related Issues screen. If the value is SELECT, then the field will appear as a select list. The user can then select the issue they want to modify in the list and then press the link button to go to an edit screen for that issue. If there are more entries in the list than the POPUP_LIST_SIZE behavior setting, then an additional entry of * More * will appear in the list. If the user selects this value and clicks on the link button, then they will be redirected to the Related Issues screen for a full list of the grouped issues. |
| RG_UPDATE_BILEVEL_ONLY | This behavior setting is for backwards compatibility with ExtraView version 4.x. If you set the value to YES, then related issue updates are only triggered when a change to the STATUS field takes place. If this is set to NO then updates to related issues may be triggered on different events and many updates to different fields are possible. |
| RID_PAGING_DEFAULTS | Related issue displays may be paged. Currently, an entire RID is shown on the add and edit screens. Page size and threshold values determine how many issues are shown simultaneously in the related issue display, with other pages navigable through via Next and Previous buttons at the bottom of the display |
| SHOW_CLOSED_REL_GROUPS_PERIOD | The list of items on a relationship group will be displayed until all issues have been closed for a minimum number of days specified by this value. Valid values are numbers equal to or greater than 0. 0 means that as soon as all items within a relationship group are of the status specified by STATUS_CLOSED_NAME they will not be displayed on the list of relationship groups. |
Data Dictionary Fields for Relationship Groups
| Field | Purpose |
| NO_RELATED_ITEMS_MESSAGE | This is the message that is provided within a related issue display when a search is performed to return related issues, but none exist. The default is There are no search results. This message is a label field within the data dictionary and it may be altered and it may localized |
| RELATED_ISSUE_DISPLAY | This label field provides a means of being able to alter the title to the inbuilt relationship issue display. Note that when you create a new relationship issue display type, then a new field is automatically created as a label field in the data dictionary, also allowing you to provide a title to the related issue display you create |
| RELATIONSHIP_GROUP_CHILD | When this field is placed on a layout, and the user enters an ID into this field, then the issue whose ID is entered becomes a child to the current issue when the current issue is updated. If there is an error, such as a non-existent child ID, an error will be generated and displayed to the user. If the current issue is already a parent of the child issue ID entered, no error is indicated and no change to the relationship occurs. When the user next views the issue, the related issue display will show the new child issue, assuming the relationship group relation type is either MEMBER, CHILD or RELATED |
| RELATIONSHIP_GROUP_LINK | A general purpose label to provide the title for relationship group links |
| RELATIONSHIP_GROUP_PARENT | When this field is placed on a layout, and the user enters an ID into this field, then the issue whose ID is entered becomes a parent of the current issue when the current issue is updated. If there is an error, such as a non-existent parent ID, an error will be generated and displayed to the user. If the current issue is already a child of the parent issue ID entered, no error is indicated and no change to the relationship occurs. When the user next views the current issue, the related issue display will show the new parent issue, assuming the relationship group relation type is either MEMBER, PARENT or RELATED |
| RELATIONSHIP_GROUP_REMOVE_BTN | A field to provide a checkbox that allows issues to be removed from relationship groups. The field is an inbuilt field with special treatment. It is defined in the data dictionary with a type of LABEL and a display type of BUTTON. Although it is placed on related issue display layouts, it will only appear when the layout is rendered within an edit screen. It is ignored on add screens, report layouts and on the POST_EDIT_UPDATE layout. There is a security permission key named PR_RESOLUTION.RELATIONSHIP_GROUP_REMOVE_BTN to control the appearance of the Remove? checkboxes on the edit screens. The user may check any number of related issues and the checked issues will be removed from the relationship when the current issue is updated |
| RELATIONSHIP_GROUP_TITLE | A general purpose label to provide titles for relationship group |
| RELATIONSHIP_GROUP_TYPE | A general purpose label to provide the titles for relationship group types |
| RELATIONSHIP_GRP_PARENT_ID | A field that stores the parent ID of a relationship group |
| RELATIONSHIP_GROUP_ID | A field that contains the internal ID of a relationship group |
| RELATIONSHIP_GROUP_PARENT | A field that contains the parent of a relationship group |
| RELATIONSHIP_GROUP_CHILD | A field that contains the child of a relationship group |
| RELATIONSHIP_GROUP_TXNS | A field that contains the historic transactions of a relationship group. This field is only valid on a layout of type HISTORY. |