User rights

Assigning rights

In Vertec, it is possible to assign user rights to a user. These user rights are then valid everywhere in Vertec.

The following user right types are possible:

• Readability of data (read)
• Executing reports and scripts
• Editable data (write, enter, delete)

User rights are always defined on user groups. All users assigned to this user group receive the user rights assigned there.

You can assign individual user rights in Vertec, with the exception of a few individual fields. Usually, rights are granted. However, if you want to effect the opposite of a user right, set the status to deny.

The corresponding user rights are assigned as follows:

To add a new user right, click on New user right. A new row appears in the list, which you can edit accordingly. The possible values are offered via drop-down lists:

To delete a user right, select the appropriate row in the list and click Delete user right.

Rights can also be assigned to individual objects. In this case, the rights only apply to the individual object and not, as with standard user rights, to all objects of a specific type.

To create an object right, follow these steps:

1. Click on the New object right button. A new row appears in the list of user rights.
2. Grant the desired right.
3. In the Object field, you can select the object:

User rights can be specified with an OCL expression. The corresponding right is taken into account only if the expression is true for the object for which the user right is being checked.

The following example checks whether the address administrator is identical to the logged-in user. If this is the case, write permission is granted for the corresponding addresses. To simplify access to the logged-in user, the variable varLogin exists, which refers directly to the current user.

When combining user rights across different user groups, the evaluation of the user right depends on the object for which the user right is requested.

The following applies to user rights with expressions:

1. When combining on different user groups, user rights with expressions at the end of the resulting user rights list are considered.
2. The expressions are only evaluated if there is a current object that can be evaluated. For example, the right to create objects cannot be linked to an expression, because at this moment there is no object that could be evaluated. Therefore, it is not possible to assign expressions to the standard user rights such as project manager etc.
3. If rights with conflicting expressions (grant, deny for the same member) are defined on different groups of a user, the order and thus the priority is not clearly defined. Care should be taken that such constellations do not occur and that the groups are clearly separated from each other.

Attention performance trap

User right expressions can lead to performance impairments. The problem is that the user right has to be checked every time a member is accessed. A “cache” is not possible, because the result of the expression can change between two callups. In particular, read rights that are assigned to entire classes (i.e. not to individual fields) have to be checked again for each individual field.

You should formulate the rights as concisely as possible, e.g. write instead of read (which is often present anyway, e.g. for addresses) or assign the rights only to individual fields.

In principle: Do not define read rights at class level without specifying the relevant fields, especially for classes that are either shown in lists (such as service, address) or used in totals (invoice).

Users are assigned to user groups, on which the rights are defined. The following must be observed:

When setting up an authorization system with different user groups, it is advisable to generally set up the groups in such a way that rights are “granted”.

The reason is the “allow before forbid” principle when combining different user groups. So it doesn’t work to create a group that can just do everything and then restrict certain rights in other groups.

It is best to start with a standard user group that cannot do anything or in which everything that needs to be denied is denied. In principle, all users are assigned to this standard user group.

Next you can set up the other user groups, in which the additional rights are granted depending on the group. Users who are then assigned to these groups receive certain rights.

If you have competing user rights such as “standard users are not allowed to read member XY, but project managers can” you have to use the same right types: If “read” is blocked, “read” must be reactivated. And if an expression is defined, the same expression must be defined on the competing user right.

Object rights are treated exactly the same as usual (class) user rights. They can only be applied to a specific object.

1. First, the built-in rights are taken into account, i.e. the user rights a user has on a particular member based on their status (project manager, supervisor, standard user, etc.).
2. The user rights from all groups to which the user belongs are then combined into a list. When combining the rights lists, the “allow before forbid” principle applies to rights that concern the same thing.
3. The rights in this combined list are scanned in order and are applied to the “built-in” user rights. For example, if first a right is granted and then denied, then deny wins.

If the user is a superuser (administrator with super rights), steps 2 and 3 are omitted.

There are a number of rights that cannot be overridden by user right lists, as they would jeopardize the smooth operation of Vertec. Examples: deactivating an administrator, making changes to invoiced values, activating users beyond the number of licenses, etc.