Access Rights for Server-Wide Objects (Level 1)

Access to rights objects is granted through roles. Groups are assigned to these roles, and individual users are assigned to groups. If a user has access to a rights object, it is implied that this user is a member of a group that is assigned to a role with access rights to that rights object.

This rights chain is shown in the view of the following three cubes from the System database:

#_ROLE_RIGHT_OBJECT cube: defines the rights on each role for every object in the database. See Rights Objects in Jedox for a description of each object.

#_GROUP_ROLE cube: establishes the roles that each group is assigned to.

#_USER_GROUP cube: defines the group that each user belongs to.

#_ROLE_RIGHT_OBJECT Cube

Rights for individual roles can be viewed in Administration→Roles→<role name>.

To make changes to the rights for each role, create a Jedox View from the #_ROLE_RIGHT_OBJECT. Set up the view as shown below:

The View looks like this:

In this view, rights objects are listed with the assigned rights for each role in columns. For details on the types of actions associated with each object, see Rights Objects in Jedox.

With all rights objects, the admin role has the highest access rights: delete or splash. The admin user is firmly anchored in the system and cannot be altered; this user cannot be deleted and its rights are firmly predetermined.

The roles of designer, etl, poweruser, editor, and viewer have standard predetermined rights at first, but they can be adapted. Further roles can also be created.

#_GROUP_ROLE Cube

This cube establishes group roles.

A group is allocated to a role by putting 1 into the cell. The admin group belongs to the admin role and cannot be changed.

Notes:

  • A user must be a member of a group with a role to log in. Otherwise, the user cannot log in.
  • A group should be allocated to only one role.
  • A single group can be a member of multiple roles. In that case, for each rights object the highest access right of either of the roles will be used. However, for maintenance and transparency of the rights model, it is typically easier to assign groups to only one role.

#_USER_GROUP Cube

This cube defines which group(s) a user belongs to.


A user is allocated to a group by putting 1 into the cell.

A few notes about the administrator:

  • The admin user belongs to the admin group; this cannot be changed.
  • To be the administrator, a user must be in the admin group; being assigned the admin role alone is not enough.
  • Only an administrator can assign users to the admin group and role.
  • Users who belong to the admin group can always see and edit cube data, even if appropriate rights for the admin group have been deleted.

Important note: 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 regard to cell data access, several rights definitions are combined for reading or writing (e.g. the DefaultRight setting, the rights for dimension element data, or the rights for cell data, which are described in Level 3 Access Rights within Specific Databases). 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.

Related links:

Updated June 5, 2023