Working with roles

Eugene Kuchynski — Mon, 16 May 2022 06:35:58 GMT

Current Revision posted to Wiki by Eugene Kuchynski on 5/16/2022 6:35:58 AM

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

An Object Permission tab controls access to object instances that fit a specified criteria.

The following image illustrates the Object Permissions tab in the Type Operation Permissions dialog.

In this example, while main type permission allows access to all Units, this object permission rule denies read/write/delete access to units where Is time box is not checked. To build this criteria, a visual filter builder was used:

Member permissions

Member Permissions controls access to specific members of an object.

For example, users can have access to objects of a particular type and simultaneously have no access to several members of this type. For other example, it is possible to deny access to objects of a particular type and only allow access to a strict list of its members. It is possible to grant access to multiple properties with a single entry.

In the example, let's say we want to allow editing of all fields of a Unit entity except adjustment factor. Then we can add a new row to this table, select Adjustment factor in the field list and deny read/write access:

Now, when a user opens list of units, this column will be hidden. Additionally, while configuring member permissions, you can use Criteria field, to provide additional conditions for applying particular rights. Built-in criteria builder will help you to compose necessary criteria.

Tags: permissions, Roles, Users, Security

Working with roles

Eugene Kuchynski — Fri, 23 Apr 2021 08:43:55 GMT

Revision 3 posted to Wiki by Eugene Kuchynski on 4/23/2021 8:43:55 AM

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

For example, when SDL Trados Business Manager was launched for the first time, few default roles were created: Administrator, Default, Vendor, Customer. 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:

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.

Click on the Edit button to open its editing form:

Object permissions

An Object Permission tab controls access to object instances that fit a specified criteria.

The following image illustrates the Object Permissions tab in the Type Operation Permissions dialog.

Member permissions

Member Permissions controls access to specific members of an object.

Tags: permissions, Roles, Users, Security

Working with roles

Eugene Kuchynski — Mon, 09 Dec 2019 06:39:54 GMT

Revision 2 posted to Wiki by Eugene Kuchynski on 12/9/2019 6:39:54 AM

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

Editing view for the Default role:

Both checkboxes are clear 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 Navigation permissions and Type permissions tabs. 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, he/she will get access to all operations. Depending on the selected value here you specify a way of working with Navigation permissions and Type permissions tabs. If default policy denies access by default, than in these tabs you will specifying objects to allow access. And vice versa, if default policy allows access, than in these tabs you will specify object to restrict access to.

The Navigation Permissions allow you to grant or deny permissions for a single navigation item or for the whole navigation group as shown on the image below:

Allowing access to Reference data group will open access to all items in this group with read only rights. By default, permission policy dines all access. After giving access to the Reference data group we expand this policy by giving additional rights. Since we use policy of restriction, given rights allow only to view data, but not edit it.

Item permissions have a greater priority than group permissions. For instance, you can deny access to the group, but grant access for one of its items, so this item will be enabled in the Navigation Panel.

The Type Permissions tab specifies access to all objects of a particular type. The image below illustrates this (in addition to previously granted access to the Reference data group, we open write rights for the Units table):

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.

If you wish to quickly fill this table with all object types available in the Business Manager, instead of manually adding rows one by one, click Pre-fill list of object types button on the ribbon:

Double click on the new type permission to open its editing form:

In this window, you can adjust access rights in detail. In addition to Read, Write, Create and Delete rights you get access to two additional tables: Member permissions and Object permissions.

Tags: permissions, Roles, Users, Security

Working with roles

Eugene Kuchynski — Wed, 17 Jul 2019 07:47:50 GMT

Revision 1 posted to Wiki by Eugene Kuchynski on 7/17/2019 7:47:50 AM

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

For example, when SDL BaccS was launched for the first time, few default roles were created: Administrator, Default, Vendor, Customer. 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:

The Navigation Permissions allow you to grant or deny permissions for a single navigation item or for the whole navigation group as shown on the image below:

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.

If you wish to quickly fill this table with all object types available in BaccS, instead of manually adding rows one by one, click Pre-fill list of object types button on the ribbon:

Double click on the new type permission to open its editing form:

Tags: permissions, Roles, Users, Security