Rights Designer

This section will go through using the Rights Designer to specify the access rights of groups of users in an application

The Rights Designer is used to setup groups with specific rights when building an application. For example, a group of users may need access granted to edit or read specific classes, see data fields or execute workflows while other users do not. We also want administrators to have the ability to have the full access. In this document we will have a look at how to create group, managing users in a group and setting permissions for various functionalities of an application.

Opening the Rights Designer

To open the Rights Designer, enter Config Mode and click on Rights.

Opening Rights Designer

Groups

The Rights Designer opens in the Groups Tab. With groups, rights can be set for a set of users at once. All users of this group possess the rights that are assigned to this group.

The Groups Tab in Rights Designer

Users

In the Users Tab, we can find a list of all users. If we have a large organisation, the list of users can become quite long. We can use the filter function to find a specific user. To use the filter function, we simply start typing the name of the user in the Filter field .

Managing Groups

Default groups: Viewer & Editor

By default, all applications are created with the two groups; Viewer and Editor. The Viewer group is set up so that it’s members can view but not edit the application whereas the Editor group extends the rights so that it’s members can also edit the application.

Creating a new group

To add a group, we simply press on the plus icon in the top left corner of the Groups tab. Afterwards, we specify a name and then click on Execute in the bottom right corner.

Creating a new group

Deleting a group

To delete a group, we simply click on the trash icon on the right of the group we want to delete.

Changing group details

In the Common Tab of a group, we can change the Name and the description of the group.

Common Tab

Assigning Permissions

The Permissions Tab allows us to assign rights to groups.

Role Permissions

In area 1, we can set the Overall Rights for the group, which will apply by default for objects. In area 2 we can set or modify rights for individual classes.

Later on, we will also see how to apply Scoped Rights form this window.

For better overview, you can expand or collapse the individual classes of area 2.

Expanding and Collapsing Classes

Adding new member

The Members Tab allows us to add or remove members to a group.

To add a member, click on the plus icon in the top left corner.

Then we can choose which users to add to the current group. We can also add groups as members of a group and this is explained under Hierarchical Organization & Inheritance.

Removing Member

To remove a member, we click on the

iconon the right side of the Member we want to delete.

Hierarchical Organization & Inheritance

The TIVITY platform allows us to hierarchically organise groups.

Using the example of Viewer & Editor. A Viewer has Viewing Permissions but no Writing Permissions. By default, an Editor is part of the group Viewer. The editor therefore automatically inherits the rights of a viewer and has the possibility to extend them.

The Member Of Tab shows us all the groups that this group is a member of.

Editor is a member of Viwer

Joining a group

To join a group, we click on the link icon in the top left corner of the Tab.

Leaving a group

To leave a group, we click on the unlink icon on the right side of the Group

Every user can have different rights to access or edit items and call functions. These are stored in a user’s detail page, which can be accessed at Rights Designer > Users Tab > Click on user

Managing Rights

Permissions can be set at user level or group level.

  • To set permissions for a specific user, navigate to Rights Designer > Users Tab > Username

  • To set permission for a group navigate to Rights Windows > Group > Permissions Tab

Overall rights and per-class rights

The Permissions Tab for both a Group and a User will look similar.

In Area 1 we can set the Overall rights which will will affect all classes. In Area 2 we can set or modify rights for individual classes. The following table describes the permissions of the class and the effect the specified permission has for the class elements :

Right

Abilities

Not set

(no rights set)

Read + Write

Users can

  • read and edit data fields

  • execute all actions

  • execute workflows

Read

Users can

  • read data fields

  • execute read actions

Users cannot

  • not execute workflows

Deny Write

Users are actively denied to

  • write data

  • execute write actions

  • execute workflows

Deny Read

Users are actively denied to

  • read or write data

  • execute actions

  • execute workflows

Scoped Rights

Permissions can also be applied to data fields, actions and workflows. This allows to granularly define how users can interact with specific items of the platform. For example, a specific user or group can be given the right to fully interact with a class but denied the right to apply all workflows defined for the object.

For this, we are back in the Permissions Tab of a Group or a User and expand an object.

For a summary of the whole permissions tab, from here we can :

  1. Set overall rights for all classes

  2. Set rights for one class of our application

  3. Set rights for the Actions of that specific class

  4. Set rights for the Fields of that specific class

  5. Set rights for the instance workflows of that specific class

Overall (1) and class (2) permissions have been covered in the previous sections. To set right for a specific Action, Field or Workflow, expand the corresponding panel.

Field

Fields permissions work similarly to class permissions, you can refer to the table under Overall rights and per class permissions for more information about those permissions.

Permissions for the App field in a class

Action and Workflow

Rights to execute an action or a workflow can either be granted or denied by setting the permission to Grant or Deny respectively.

Rights to execute action or workflow can be either grated or denied

Conditional Permissions

For every Action, Field and Workflow, it can be specified whether a permission is granted depending on the state of a conditional variable. For example, a workflow for an object can only be executed by the user when the object has the defined value.

Firstly, open the drop-down list for an object. Then click on Actions, Fields or Workflows, depending for what type you want to set the conditions and click the settings icon .

In the Conditions Tab, several settings can be adjusted to fit the conditions of the permissions and denials to your specific use case.

For example in the last figure, the Save Action is granted only if the Object's Name field is not empty.

In the Overall drop down, you can specify whether the access to this field is granted or denied by default. There are three options:

Option

Details

Not set

No condition is applied to this action/field/workflow (initial value)

Grant

This action is by default granted for the user unless other specified by the following conditions

Deny

This action is by default denied for the user unless other specified by the following conditions

Then, using the Matches drop-down, you defined whether items that match the following conditions are included or excluded.

Option

Details

None

No conditions are relevant for this item

Included

The right is applied to all instances that fit the conditions

Excluded

The right is not applied to the instances that fit the conditions

There can be single conditions or groups of several conditions that the object must match in order for the right to apply.

Copy permissions and conditions

The set permission and conditions on one object can be copied to member of the same object:

  • Class right: The permission and conditions can be copied to the same class of other roles of the same application (at least one role must be selected)

  • Action right: The permission and conditions can be copied to other actions of the same class and for other roles of the same application (at least one action and one role must be selected)

  • Field right: The permission and conditions can be copied to other fields of the same class and for other roles of the same application (at least one field and one role must be selected)

  • Workflow right: The permission and conditions can be copied to other workflows of the same class and for other roles of the same application (at least one workflow and one role must be selected)

To save a set of permissions and conditions press the Copy button at the bottom left of the window.

An overlay with multiple selection fields opens. You can now select the objects to which the set will be copied. Execute Copy after the selection.

Overlay with selection

Last updated

Was this helpful?