# Rights Designer
The Rights Designer is used to set-up roles with specific rights when building an application. For example, a role 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 roles, managing users in a role 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**.
## Roles
The Rights Designer opens in the **Roles Tab**. With roles, rights can be set for a set of users at once. All users of this role possess the rights that are assigned to this role.
## Users
In the **Users Tab**, we can find a list of all users. If we have a large organization, 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 Roles
### Default roles: Viewer & Editor
By default, all applications are created with the two roles; Viewer and Editor. The Viewer role is set up so that it’s members can view but not edit the application whereas the Editor role extends the rights so that it’s members can also edit the application.
### Creating a new Role
To add a role, we simply press on the **plus icon** in the top left corner of the Roles tab. Afterwards, we specify a name and then click on **Execute** in the bottom right corner.
### Deleting a role
To delete a role, we simply click on the **trash icon** on the right of the group we want to delete.
### Changing role details
In the Common Tab of a Role, we can change the following:
* **Name** – The identifier of the custom role.
* **Description** – A short explanation of the role’s purpose.
* **Assignable by Users** – A checkbox that determines whether the role can be assigned to Groups within the Teams app.
If this option is **checked**, the role will appear in the **Team** app and can be assigned to users or groups.
If the option is **unchecked**, the role will be hidden from the Team app and cannot be assigned manually.
#### Behavior and Version Control
All **newly created custom roles** (specified roles) are **assignable by users by default**.
If a role is made unavailable in the **Rights Designer** by unchecking *Assignable by Users*, the following will occur automatically:
* All rights or restrictions previously granted by that custom role will be **removed** from users and groups.
* The same behavior applies when a role’s assignable status is changed as part of an **app version update**.
The **Team** app also offers the option to **export and import group rights**.
If an exported group includes a specified role that is **unmarked** (meaning it is not assignable by users), and the same group rights are later imported where that specified role was **marked**, it will become **unmarked** and all related rights will be **automatically removed**.
This ensures that imported configurations remain consistent with the current state of available roles and their permissions.
### Assigning Permissions
The **Permissions Tab** allows us to assign rights to roles.
Role Permissions
In area 1, we can set the **Overall Rights** for the role, 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](/managing-users-and-collaboration/roles-and-permissions/rights-designer.md#scoped-permissions) 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 role.
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 role. We can also add roles as members of a role and this is explained under [Hierarchical Organization & Inheritance](/managing-users-and-collaboration/roles-and-permissions/rights-designer.md#hierarchical-organization-and-inheritance).
### Removing Member
To remove a member, we click on the
**icon**on the right side of the Member we want to delete.
### Hierarchical Organization & Inheritance
The TIVITY platform allows us to hierarchically organise roles.
Using the example of Viewer & Editor. A Viewer has Viewing Permissions but no Writing Permissions. By default, an Editor is part of the role 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 roles that this role is a member of.
#### Joining a role
To join a role, we click on the **link icon** in the top left corner of the Tab.
#### Leaving a role
To leave a role, we click on the **unlink icon** on the right side of the Role.
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 role level.
* To set permissions for a specific user, navigate to **Rights Designer > Users Tab > Username**
* To set permission for a role navigate to **Rights Windows > Roles > Permissions Tab**
### **Overall rights and per-class rights**
The Permissions Tab for both a Role 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 role 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 Role 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 ](/managing-users-and-collaboration/roles-and-permissions/rights-designer.md#overall-rights-and-per-class-rights)for more information about those permissions.
#### 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.
### 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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.tivity.one/managing-users-and-collaboration/roles-and-permissions/rights-designer.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.