In Jedox, access rights are hierarchically defined as follows:
|S (splash)||Exists only for the rights object “cell data”. It includes writing into consolidated cells and (indirectly) their children down to the lowest level.|
|D (delete)||Access rights for deletion.|
|W (write)||Access rights for writing.|
|R (read)||Access rights for reading.|
|N (none)||No type of access permitted.|
Higher-level rights automatically include the subordinate-level rights. The highest access right is expressed by the term “splash “, but it refers only to the cell data. For all other rights objects, “delete” is the highest access right.
Access right definitions are stored as values in cubes and can be modified like any other cube values, such as by creating a view of the cube and then editing the cell value by direct input or by double-clicking the cell to open the string editor. It is also possible to have an empty cell in a system cube. The meaning of an empty cell, i.e., the applied default value, depends on the respective system cube.
For a specific user, access rights are inferred from rights of the group(s) the user is a member of, and from the roles of these groups. There are three general levels on which access rights are defined:
- On Level 1, roles are granted access to server-wide rights objects. These access rights are located in the System database.
- On Level 2, groups are granted access to database objects. These access rights are located in the System database.
- On Level 3, groups are granted access to the objects (cubes, dimension elements, and cube cells) within a specific database. These access rights are located in special, automatically created cubes within the specific database.
The most effective user access right for the rights object “cell data” is the lowest right given for this user in one of the three levels. The most effective user access right to all other rights objects (except “cell data”) is the lowest right given for this user in one of the first two levels.
User rights information is contained in the System cubes of the System database. For more information, see Database System Cubes.
Effects of rights on calculations
Rights of any kind never affect computations or consolidations. For example, a “none” right in the cube #_GROUP_DIMENSION_DATA_ <Name of dimension> does not influence the calculation of dependent contents in consolidated cells.
Assigning users to multiple groups
A user can be a member of several groups. An operation like reading a cell value is allowed for a user if the user is in at least one group with the required access rights. Note that in regards to cell data access, several rights definitions are combined for reading or writing (e.g. the “DefaultRight”, the rights on dimension element data, or the rights on cell data, which are described in “Access Rights within Specific Databases (Level 3)“). Here, the comparison of rights for the user’s multiple groups is made not object by object, but for the full rights sequence. For each of the user’s groups, there is one effective right for the cell data access in any specific case. Of these effective rights for each group, at least one has to be as high as the required right for the operation.
Effects of rights on hierarchy views
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.
Aggregated elements pass on rights to subordinate ones as long as the latter do not have any rights defined of their own. Consequently, “splash” rights make it possible to change cell data of consolidated cells directly. In splashing (i.e., writing in consolidated elements), “splash” rights are dominant in the sense that the rights of children are being ignored. If an element below a splashed element has “read” rights, this is ignored during the splash procedure.
However, splash rights do not dominate for pure reading rights. Any possible “none” rights below “splash” rights will be respected. In other words, as long as a user has writing rights for the current consolidation level and otherwise has splash rights, that user may splash. If the user only has reading rights for the current consolidation level, then that user may not splash. The right “N” below that, however, would be factored in. Consequently, the combination of splash and the rights of the consolidated element in question is the deciding factor.
Users without a group role
A user must be a member of a group with a role to logon. Otherwise, the user cannot logon.
Modifying rights during a session
The server responds dynamically if the association of a user to a group is changed during an ongoing session of this user.