Child pages
  • "Validity" in hierarchy authorizations
Skip to end of metadata
Go to start of metadata

Symptom

When maintaing a hierarchy authorization, you select validity area 1, 2 or 3. This enhancement either does not seem to work all the time or it does not seem not to work at all. The query returns "No authorization".


1. Program logic

1.1 Definitions

During each authorization check, the current selection (= What does the customer want to see?) is compared with a specified authorization (= What is the customer allowed to see?).
In a hierarchy authorization, authorized data is specified as follows:

  1. The name of the authorized node (and the depth of the area under the node).
  2. The hierarchy - it is defined precisely using the following:
    1. Name of the hierarchy
    2. Version of the hierarchy
    3. Key date of the hierarchy

The first part (the node name) is always fixed. You can set the second part (for which hierarchy you want the authorization to be valid) by specifying the validity.

  • 0 (Name, version and key date-relevant)
  • 1 (Only name and version-relevant)
  • 2  (Only name-relevant)
  • 3  (Valid for hierarchies)

Of course, in two different hierarchies, two nodes with the same name may be completely different.

A hierarchy node-selection has a comparable structure. It specifies:

  1. The name of the selected node (and the depth of the area displayed under the node).
  2. The hierarchy of the current selection - it is defined precisely using the following:
    1. Name of the hierarchy
    2. Version of the hierarchy
    3. Key date of the hierarchy

This specification of the selection is always fixed by the selected data query.

1.2 Check logic during node selection

How is a check carried out, in particular, if the validity is not unique?

For validity = 0, the situation is simple:
In the selection, the following is defined precisely: Node name (with drilldown depth) and hierarchy (name, version, key date). This is now compared with all the hierarchy authorizations of the user in order:

First, the specifications for the hierarchy are compared. All hierarchy authorizations that do not correspond exactly in the hierarchy are rejected. Then the system checks whether the selected area (node with drilldown) is in the authorized area. This is the case if either the selected node corresponds to an authorized node,  or if the selected node is a subnode of an authorized node. In this case, the drilldown depth of the selected node must be within the specified depth of the authorized node. If this is the case for one of the remaining hierarchy authorizations, the check returns "ok".

For validity = 1, 2 or 3, the logic is rather more complicated:
The selection is still fixed precisely: Node name (with drilldown depth) and hierarchy (name, version, key date). This cannot change.

First, the system checks all the hierarchy authorizations of the user, and rejects any unsuitable hierarchy authorizations. This is where the validity setting is used. A hierarchy authorization can be "valid" if it falls within the specified limits, even if it does not correspond exactly to the hierarchy in the selection. Then the system checks whether the selected area (node with drilldown) is in the authorized area. If the names of the selected node and the authorized node correspond, this check is not important. Only the drilldown depth must still be authorized accordingly.

For the check to see whether the selected node is a subnode of the authorized node, the following logic must be taken into account: This check takes place in the hierarchy (= hierarchy structure) of the selection, and not in the hierarchy that is specified in the hierarchy authorization. From the hierarchy authorization, only the name of the node (and the depth of the authorization) is used. What is actually authorized is the node with this name in the hierarchy of the selection.

Note 1: It is important to realize that the hierarchy structure of the selection is used if the structures of the hierarchies in the selection and authorization are different.

Note 2: A "reverse logic", that is, using the hierarchy from the authorization could be considered in principle: However, then the system would have to first search for all hierarchies that correspond to a hierarchy authorization with open validity (1, 2 or 3). Then, in all of these hierarchies, the system would have had to check whether the selected node was under the authorized node. This logic would not be feasible because it would lead to serious performance problems in some cases.

1.3 Check logic during value selection

Up to now, we have stressed the following: During the check, the hierarchy structure of the selection is relevant, and not the hierarchy structure of the hierarchy authorization.

However, the situation is different if the selection is not a hierarchy selection (with node name and hierarchy), rather it is a "flat selection" (= single value). Then the selection does not contain any specifications for a hierarchy. A flat selection from a hierarchy authorization can be authorized if the relevant single values are authorized leaves of the hierarchy. (Hierarchy leaves are characteristic values.) The question is only: Which hierarchy structure should now be used for the evaluation? The selection does not have its own hierarchy. Therefore, the logic is changed.
The individual hierarchy that is specified is used: This is the hierarchy from the hierarchy authorization. The validity of the hierarchy authorization used does not play a role here: It is the hierarchy of the authorization (name, version, key date) that is evaluated.

Note 3: As in note 2, another logic could also be considered here: If the validity is variable (1, 2 or 3), the system could first search for all "suitable" hierarchies and then evaluate them all.
This logic could not be used because it would lead to serious performance problems in some cases.

1.4 Special case: Leaf selection

If you want a single value to be selected in a query with a hierarchy, you can select the relevant leaf in the hierarchy. In the display of the executed query, a distinction is not made between a selected single value (flat selection) and a leaf selection. The data displayed is the same. However, from a technical point of view, there is a difference: the leaf selection contains complete hierarchy information, however the single value selection does not.
If a leaf is selected in a query, for example, using a node variable, the check is carried out as follows:

  1. Since a leaf (like a node) is a hierarchy element, the normal nodecheck is carried out according to the logic specified in section 1.2. What is relevant is the structure of the hierarchy in the selection.
  2. However, since a leaf is also a single value, a value check also occurs (if necessary) according to section 1.3. In this case, what is relevant is the structure of the hierarchy in the authorization, as mentioned above. ("If necessary" means: The value check occurs only if the node check was unsuccessful.) Therefore: Leaves are checked after both procedures.

Note 4: A possible consequence of this logic is that the system may display all the leaves of a node, for example. However, the selection of the directly superior node returns "No Authorization". It is also possible that out of two different queries that should display the same characteristic value, only one may be authorized. It is up to the administrator to set up the queries and/or authorizations so that the authorizations correspond to the query design. For this, the logic described must be known and relevant tests must be carried out.

2. Examples

Here is a detailed example of how the logic of the extended validity works:

2.1 Setup

The values of a "customer"- characteristic are located in different parts of the world-hierarchy "WORLDHIER". "WORLDHIER" is a geographical hierarchy that groups the customers by countries. The hierarchy has two versions.
In version 1, the customer "Jones" belongs to USA:



In version 2, the customer "Jones" belongs to Puerto Rico: 

The following hierarchy authorization was defined:

    o  Node = "USA" (depth = 1 "complete subtree under node")

    o  Hierarchy:

               1. Name = "WORLDHIER"

               2. Version = 2   (that is, "Jones" hanging under node "Puerto Rico")

               3. Key date = 12.31.9999

    o  Validity: 2 (= "Name identical") The version is therefore not
       defined.

2.2 Example: Node selection

The following hierarchy node is selected in a query:

    o  Node/leaf = "Jones"

    o  Hierarchy:

               1. Name = "WORLDHIER"

               2. Version = 1   (that is, "Jones"hanging under node "USA")               

               3. Key date = 12.31.9999

This query selection is checked successfully. Data is displayed.

Reason:
First the authorization is not rejected because it is classified as "suitable" under the validity 2 (name identical). Therefore, the node "USA" contains an authorization. Then the system checks whether the node "Jones" (which is actually a leaf) is in the hierarchy version 1 under the authorized nodes. If it does, the selection is authorized.

Please note again: In this case the hierarchy structure of the selection is taken when determing the authorized area of the user. Therefore only the node-name maintained in the hierarchy-authorization is relevant.

2.3 Example: Single value selection

In a query, "Jones" is selected as a single value (no hierarchy). This query returns "No authorization".

As described above: Single value selections are checked against existing hierarchy authorizations. However, the query selection does not contain any information about hierarchies. Version 2 is then used in the check (from the definition of the authorization). However: In version 2, the node/leaf "Jones" is not under the authorized node "USA". Therefore the single value "Jones" cannot be authorized using the hierarchy authorization. This query receives "No authorization". The extended validity area has no effect here.

Note 4: The comparison with test case 2.2 shows that, for the same hierarchy authorization, the display of a value (here: "Jones") may depend on the query definition. In one case, the flexible validity (= 2) has an affect, in the other case it does not.

  • No labels