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 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:
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.
