1. Administration of Hierarchies

Portal Administration module provides access to the hierarchies management under the NEXThink Portal Management section, dashboard Hierarchies.

Using hierarchy permits to organize results in widgets using a detailed structure and drill-down features and manager access rights to information.

Hierarchy example:

1.1. Adding a hierarchy

1.1.1. Creating the structure

• Click on the add hierarchy button in the toolbox
• Set the hierarchy name
• Set the levels of the hierarchy. Here two levels will be created. A first level is always present and corresponds to the category level (called entities). This level can be renamed but its position cannot be changed.
• Select the category on which the hierarchy will be based on. Only the category created using a CSV file can be used as base for a hierarchy.
• Note that an implicit root node will be created.

  
  

Once the hierarchy structure created, you can see each keyword defined for the category in a table with their path. In the upper part each level is represented with the list of entries. Initially, all keywords are placed in branch '-' which is the default branch.

1.1.2. Editing entities

Editing the entities permits to define the hierarchy tree. Create, move or merge branches could be done by inserting the appropriate name.

To edit entities, follow these steps:

• Select entities to edit. The table allows multiple selection using ctrl or shift keys.

  
  

• Click on Edit selected button

• Set values for each level. These values will be applied to all selected entities

  
  

• If values are not the same for all selected entities then [multiple] is displayed and means that this value will remain unchanged if not edited

  
  

• To help the edition and prevent same values written differently, a list of available values is proposed.

  
  

When all entities have been edited and the tree is complete, each entity has a full path. The list of each level permits to filter results and to see which entity is in which path.

Before leaving the widget, or any action which implies to leave the current hierarchy you must save the performed modifications. To prevent losing your whole work, a dialog is displayed when it has been not saved.

If some domains are broken, an information will be displayed about the impact of these changes. If the user decides to continue then all objects listed in the dialog will have their domain broken. If the user cancel the changes then he can leave the current hierarchy to revert the changes or he can do other edit to reduce impact.

1.1.3. Export/Import

To backup and restore hierarchies, export and add from csv buttons are available. To restore a hierarchy, the category on which it is based on must exist. If keywords specified in the hierarchy doesn't exist they are removed and new keywords are automatically added in the special - branch.

If the hierarchy name specified in the file doesn't exist then a new hierarchy is created, if it exist then the hierarchy is edited.

1.2. Adding an Engine level

It is possible to add a special level, the Engine level. Only one such level could be added per hierarchy. And like the entities level, it could not be moved up or down but it could be renamed. It is always located just before the entities level and it could not have another level between them.

This level is automatically filled using request on Engines to know which keywords is on which Engine. It implies that it is really necessary that a keyword is only on one Engine.

This level could be added on an existing hierarchy.

1.3. Clean hierarchy

It is possible that the hierarchy as used in the Portal does not correspond anymore to existing keywords. Two typical cases could reach to a such situation.

• A keyword has been removed from the CSV file which defines the category
• An Engine is temporarily unreachable

When a keyword could not be retrieved on the Engine then it is displayed with a ! symbol but they are not deleted.

In the first case, and generally when an entity must be removed from the hierarchy, the clean tool should be used. It is available only if there are some unused entities in the current hierarchy.

The dialog displays the list of entities which are not present actually on Engines. The selected rows will be deleted from the Hierarchy.

Note that if an entity is removed and the next time is retrieved on an Engine, the Entity will be again in the table but without node values.

1.4. Rename a level

Once created, it is not possible to rename a level using the edition of hierarchy dialog. But it is possible to rename a level using the link directly next to the level name. Using this link permits to apply this change everywhere in the Portal. It means that domains will reflect this change directly.

In the picture above, the level has a wrong name, "Regio" instead of "Region". Click on the rename link will open a new dialog with the current name, replace this name by the new one and click on OK. Then the level will be renamed.

1.5. Rename a node

In the same manner as renaming a level, it is possible to rename a node.

There is a very important difference between "Edit Entities" and "rename a node". Edit entities permits to edit multiple node in one time and it permits also to merge branches or create a new one but all this operations implies that existing domain will be broken. When modifications using this button have been done, the hierarchy must be saved to backup the changes.

With the renaming, only one node could be renamed in the same time but this change will be applied on all existing domain using this node. It means that domains are still valid, there is no impact and there is no need to save the hierarchy since it is already applied. As we have seen before with "Editing entities", operations on the tree are performed by renaming node but in this case only renaming is allowed, it means that the name should be unique (avoid merge or move).

The node to rename must be selected in the filter and then click on the link. All nodes corresponding to selection in filters are renamed. It means that if "all" is selected in the first level and "North" in the second then all "North" nodes in all branches will be renamed. But if "HR" and "North" are selected then only the node "North" on the branch "HR" will be renamed.

1.6. Overview mode

When multiple hierarchy have been defined, it is possible to use the overview mode. In this view all hierarchies are displayed in a single table.

It is possible to edit entities, but in this mode all hierarchies could be edited in the same time.

It correspond to a classic edit entities meaning that a save is required to backup changes in all hierarchies.

2. Influence of Hierarchies

2.1. Widgets

Once a hierarchy has been created, it can be used to group results in some widgets. Depending on widgets, it offers a navigation through the hierarchy and permits to view the value for each node.

2.2. Administration

With a hierarchy, every created component (Module, Dashboard, Widget, Account, Role..) have a reference on the domain of the creator. It means that administrators could have different content in their administration widgets. They cannot manage everything but only what was created with the same domain or below in the tree.

2.3. Delete hierarchy

If a hierarchy is deleted then it will have an impact on all objects related to it so be careful before deleting a hierarchy. The following effects will be experienced (not exhaustive list)

• Administrator based on this hierarchy couldn't login anymore
• Objects created with a domain on it will be viewable only by super administrators
• Accounts with a view on it will see nothing, correspond to no access on this hierarchy