Administration of User Rights

Typically, users of Jedox are supposed to have access to different functionality. While some users should be able to administer Jedox, others might only be allowed to work with databases, or only to view reports and enter data such as planning figures. With Jedox it is possible to define general user roles, add groups to these roles, and then add individual users to groups. Roles, groups, and users are then granted (or denied) access to both functionality, and contents (such as specific databases or reports).

For setting access rights for a specific file, right-click on the file in the Designer, and select the Security tab.

For setting access rights in different components of Jedox (Modeler, Integrator, Scheduler, etc.), open the properties, and expand the security tab.

It is possible to simultaneously set rights for multiple groups in the security dialog. To do this, first multi-select groups using the shortcuts Ctrl + click or Shift + click. After selecting multiple groups, click on one of the right options (Full control, Write, Read, Default) to apply this right to all the selected groups.

In Jedox, the access rights are hierarchically defined as follows:

S (splash)	Exists only for the cell data rights object. It includes writing into consolidated cells and (indirectly) their children, down to the lowest level.
D (delete)	Access rights for deletion of specific objects
W (write)	Access rights for writing or changing objects
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 special cubes and can be modified like all 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, governing general functionality. These access rights are stored in the "System" database.
On Level 2, groups are granted access to database objects. These access rights are also stored 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 stored 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, N rights on specific elements in the cube #_GROUP_DIMENSION_DATA_ <Name of dimension> will permit a user (group) from seeing the data on those elements, but it does not influence the calculation of dependent calculated values in consolidated cells to which the user may have access.

Assigning users to multiple groups

A user can be a member of several groups. An operation such as 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 rights 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.

Consolidated 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 Write rights for the current consolidation level and otherwise has Splash rights, that user may splash. If the user only has Read rights for the current consolidation level, then that user may not splash. The N rights below that, however, would be factored in. Consequently, the combination of Splash rights 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 log in. Otherwise, the user cannot log in.

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. If an active user belongs only to one group, the removal of that group will force the user to logout/terminate the session. If an active user belongs to several groups, the removal of the group that solely provides the rights to certain Jedox Web objects (such as Reports, Designer, Modeler, etc.) can cause refreshing problems with the UI. These problems will be resolved when the user logs in again.