In the navigation tree, select Security > Roles. Start with creating a new role or editing existing one.

For example, when Trados Business Manager was launched for the first time, few default roles were created: Administrator, Default, Vendor, Customer, PM. As it is clear from its name, administrators has full access to all data. From the other hand, users with Default role do not have access to any data at all. Try to login with the User user name and you will see that navigation tree is almost empty - access rights are fully limited.

Editing view for the Default role:

Is administrative box is not checked, and in the Permission policy field Deny all by default value is selected. This means that users with this role would not get access to any data unless you explicitly allow it in the Type permissions tab. You can change Permission policy value to Read only all by default and Allow all by default. In the first case, a user will get access to all data without ability to edit it. In the second case, a user will get access to all operations. Depending on the selected value here you specify a way of working with the Type permissions tab. If default policy denies access by default, than in this tab you will specifying objects to allow access. And vice versa, if default policy allows access, then in this tab you will specify objects to restrict access to.

The Type Permissions tab specifies access to all objects of a particular type. The image below illustrates this:

From now, user with Default role assigned will be able to edit Units table, but would not be able to delete any records from it.

You can check and uncheck permission flags right in this list, but each type permission also has detailed configuration screen. If Read, Write, Create and Delete flags control permission for all objects, in the detailed configuration screen you can allow or deny these operations by applying additional criteria to objects (for example, allow editing 'Words' unit but deny editing 'Hours' unit).

Click on the Edit button to open its editing form:

In this window, you can adjust access rights in detail, on a level of individual objects and individual fields of these objects. In addition to Read, Write, Create and Delete rights you get access to two additional tables: Member permissions and Object permissions.

Combining roles

By creating multiple roles and selectively assigning them to users, you can create complex role combinations. However, you can choose how application behaves to determine access rights. By default, the system uses Granted in all roles approach, which means that a user will have read/create/modify/delete access right if it is granted by ALL attached roles.

Example. For example, you create a role when user can view and edit all translation jobs, and you wish to limit access only to jobs for Customer A. In this case, there could be 2 roles: first role allows access to all jobs, and second role sets DENY (read/write/delete checkbox is unchecked) criteria for jobs where customer equals to Customer A.

You can use appsettings_global,json file to change this behavior. By changing value of the RoleMerging parameter to any value (and restarting application or application pool after this change), application behavior will change - access will be granted if ANY role allows some kind of access. In the example above, user will still have access to Customer A jobs, because first role allows access to all jobs. To achieve the same result, in the first role you can add criteria (Customer does not equal to Customer A). Such approach allows to create a schema when you can easily combine many roles to construct a role with required access rights. For example, you can create separate roles providing access to entities depending on customer categories, and then add necessary roles to a user to provide them access only to specified categories. However, default approach requires to create roles which serve as exclusion rules, when first role provides full access, and additional roles "remove" some kind of access.

Object permissions

Member permissions