Reporting Hierarchies - Product Documentation

Reporting hierarchies allow the administrator to set up relationships for reporting purposes. These relationships may be more than just a single level with a single parent and single child. You can set up reporting hierarchies of up to ten levels although it is unlikely that use cases go beyond three or four levels.

Some examples of reporting hierarchies may be:

Customers Customer Issues	A single customer may report many issues, and you may want to display customer information such as their name, contacts, and email addresses on a report along with the details of all the individual issues that were reported by the customer, such as the issue title, status and resolution.
Requirements Engineering Orders	You may want to set up a business area within ExtraView that has the high-level requirements to build new products. Each of these high-level requirements may be the parent of many individual engineering orders that build the component parts of the new product.
Line of Business Action Plans Action Items	A company may be split into many lines of business, and each of these lines of business may have a number of high-level action plans, which themselves are broken down into action items. This can be represented by a reporting hierarchy.

The relationships between the parent and child levels of the reporting hierarchies are represented by relationship groups within ExtraView. Please see the section of this guide on how to set up and maintain Relationship Groups, and to see how issues are placed within these relationship groups.

A reporting hierarchy is simply the definition of the structure that makes it possible to create and view reports based upon the relationship groups. For instructions on how to create a report that uses a reporting hierarchy, see the Column Report section in the ExtraView User Guide.

To create a report hierarchy, select the Reporting Hierarchies entry on the Site Configuration tab of the Administration section of ExtraView. This presence of this menu entry is controlled by the security permission keys named CF_HIERARCHY and CF_HIERARCHY_LEVEL. If you grant access to one of these permission keys, you should grant access to both in order to be able to set up the reporting hierarchies. The following screen is displayed when you select the Reporting Hierarchies option:

Reporting hierarchies management

From this screen you may use the Add button to create new hierarchies, use the Edit button to alter the title of an existing reporting hierarchy, use the Delete button to eliminate an existing reporting hierarchy, or use the List button to manage the hierarchy.

Adding a new reporting hierarchy offers you a simple screen where you enter the fixed name and the title of the hierarchy as seen below:

Adding a new reporting hierarchy

Once you have entered a fixed name and the title, click the Add new hierarchy button. To add a new hierarchy level to an existing hierarchy, click on the List button from the Reporting Hierarchies Management screen. You will see the existing levels of the hierarchy, and you can add additional levels to this. This screenshot shows an existing reporting hierarchy level of one level:

Single level reporting hierarchy

If you use the Edit button to alter the metadata at this level, it will look similar to this:

Editing a hierarchy level

Note from the screenshot that the level is 1 and this cannot be changed. As you add new levels to the hierarchy they will automatically be set at an incrementally higher level. So, the next level you add will be 2, etc. When adding a new hierarchy level you must choose an existing relationship group to represent the relationship, and you will then choose the relationship type. This must be one of Children, Parents, Related, Members, Linked or Siblings. These are defined in the section on relationship groups. The selection for the Business Area and the Project on this screen should be set to those of the lowest level of the hierarchy. This is necessary to ensure that report results are filtered correctly. For example, if your relationship type is Children, then the Business Area and Project of the child level should be selected.

The above series of screenshots represent a reporting hierarchy of customer issues, where customers are the parents of issues.

The Business Area and Project in the last screen have special significance. If the behavior setting named DISPLAY_ALL_FIELDS is set to a value of NO, then the following the following behavior restricts the fields visible as filters:

Set the behavior setting to a specific business area and project that represents an edit layout
The normal rules of inheritance are obeyed if there is no edit layout at that business area and project level
When you create or edit a report using the hierarchy, then only the fields on the edit layout and its sublayouts will be used to populate the field list for this level in the hierarchy. The normal security permission rules also apply.

This behavior helps provide clarity on the report editor screen. It is highly unlikely that a user will ever want to select a field at a hierarchy level that is not present on the edit screen and this behavior will most probably reduce the number of selectable fields at a level in the hierarchy from hundreds to tens.

Filtering the Number of Issues within the Levels of a Hierarchy

In the filter list for reports which support hierarchical filters, there is a field with the title of Related Issue Count (its name is EV_HIERARCHY_LEVEL_COUNT). This may be used as a filter on any level of the hierarchy, and will provide a count of the issues in the next level of the relationship. For example, you might want to display child records when there are more than or less than a number you provide.

You can also use this field as a sort field on report output by clicking on the title to the field. The field is a built-in field within the data dictionary and has the name EV_HIERARCHY_LEVEL_COUNT.