Rights Designer
This section will go through using the Rights Designer to specify the access rights of groups of users in an application
Last updated
This section will go through using the Rights Designer to specify the access rights of groups of users in an application
Last updated
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.
To open the Rights Designer, enter Config Mode and click on Rights.
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.
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.
In the Common Tab of a group, we can change the Name and the description of the group.
The Permissions Tab allows us to assign rights to groups.
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.
The Members Tab allows us to add or remove members to a group.
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.
To remove a member, we click on the
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.
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
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
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
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 :
Set overall rights for all classes
Set rights for one class of our application
Set rights for the Actions of that specific class
Set rights for the Fields of that specific class
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.
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.
Rights to execute an action or a workflow can either be granted or denied by setting the permission to Grant or Deny respectively.
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.
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.
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.
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 .
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.
To delete a group, we simply click on the trash icon on the right of the group we want to delete.
To add a member, click on the plus icon in the top left corner.
iconon the right side of the Member we want to delete.
To join a group, we click on the link icon in the top left corner of the Tab.
To leave a group, we click on the unlink icon on the right side of the Group
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 .
