Effects of rights on hierarchy views

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Effects of rights on hierarchy views

    Hi All,
    According to the following documentation, restriction on child nodes will not affect the aggregated parent element. But we have the following requirement which is very common among customers

    Department Hierarchy has the following structure

    ALL
    - 10
    - 20
    - 30
    - 40
    - 50

    User A has the following access rights:

    ALL (D)
    - 10 (D)
    - 20 (D)
    - 30 (N)
    - 40 (N)
    - 50 (N)


    According to the above, the report should display the sum of Dept 10 & 20 when the user select 'ALL' from the Dept Drop-down, but it doesn't. It displays the total of Dept 10+20+30+40+50

    I find it hard to believe that Jedox cannot cater to this out of the box.


    knowledgebase.jedox.com/jedox/security/rights-users.htm

    In complex hierarchies, removing access rights for a user affects the structure of the dimension hierarchy and, thus also influences subset results. For example, a user group with N rights on the four Qtr. elements and R rights for the base elements (months) would not see the base elements as descendants of the Year element. Instead, they would be listed as elements on the highest hierarchy level. Thus, a subset filter for children of Year would not return these base elements. However, the aggregated result of Year would not be influenced by this constraint; it would still be the sum of all base elements.
  • I agree, this should come out of the box by jedox...
    However, there are some workarounds for this issue.

    Case 1 - Just reporting:
    In this case you can use sum formula which includes a palo.datav forumla in combination with a subset (named range) on the coordinate you have userrights applied on. "=sum(palo.datav(connection,Coordinate1, Coordinate2, _Coordinate3_Subset)). The _Coordinate3_Subset has to have the childelements your user has rights for.

    You could also use a rule in a similar way.

    Case 2 - Planning:
    To splash on palo.datac forumulas you would have to use SVS I guess. In that script you could create a temporary parallel hierarchy in which you include all elements the user has rights for and splash the value on this hierarchy. A combination of username and the element the user wants to splash on as the hierarchy name for example. Then you would have to delete this hierarchy again within the SVS.

    The post was edited 1 time, last by hafnera ().