Managing access rights

The software comes with Access Rights Management feature that allows you to customize software's permissions. This feature is disabled by default in CodeTwo Exchange Rules, however, you can easily find it in the top menu bar (Fig. 1.) and enable by checking Switch on Access Rights Management checkbox (Fig. 2.) and submitting changes.

Fig. 1. Access Rights button on the top menu bar of the Administration Panel.

How does it work?

Older releases of CodeTwo Exchange Rules featured user-based access rights model i.e. where rights were configured individually per each user given access to the software administration. In version 2007 4.6 (deprecated) / 2010 3.6 (deprecated) / 2013 2.6 this was changed to role-based rights management model to make easier managing access rights for bigger number of users and to better addresses admins' security needs.

In CodeTwo Exchange Rules you create a list of roles (four most common usage examples are already added). Roles define access level to particular features of the program. For each role, you assign users that inherit role-defined permissions. The same user can be added to multiple roles that grant him or her different access rights. Permissions from different roles will be added in such scenario. Additionally, for each role you can customize per rule access.

Old access rights conversion

If you had any rights configured in version 2007 4.5 (deprecated) / 2010 3.5 (deprecated) / 2013 2.5 or older, these are going to be automatically converted to the new access rights model introduced in version 2007 4.6 (deprecated) / 2010 3.6 (deprecated) / 2013 2.6 upon updating or upgrading. In general, the software converts each user, group or external user old access rights to a separate access role. However, the software will attempt merging roles together - this will be successful only for users who have had identical set of permissions in previous version.

Roles management

You can freely edit existing Access Roles, clone or remove them and add new ones in Access Rights Management window using appropriate buttons. The order of roles on the list does not have any impact on permissions. Members of roles can be added as domain users, domain groups or custom external users.

Fig. 2. Access Roles list and General tab of Access Rights Management.

Access rights rules are pulled from the server upon Administration Panel start - if other user modifies access rights while you have the Administration Panel open, you will not see those changes until you restart the application.

Predefined Access Roles

As presented in Fig. 2., Access Rights Management window displays list of Access Roles. A few most useful ones are preconfigured:

Program and rules administrators - this is a full access kind of a role that can manage rules and access all features in the software, including administrative ones. By default, the software automatically adds Administrators group to this role, when you enable Access Rights Management for the first time. This is to make sure that at least one account has permissions to manage access rights, so you do not lock yourself out of the software.

Rules administrators - this role has full access to rules configuration but is not allowed access to rights management and program administrative features.

Signatures editors - quite limited role created for people who should be allowed only to manage signature-related actions. For example, you can assign your marketing department staff or graphic designer(s) to this role so they can create nicely looking signatures, disclaimers or advertisement banners but should not be able to touch anything else, other than signature/disclaimer adding action properties. So, members of this role will not be able to edit other rules nor even conditions, exceptions and other actions within signature/disclaimer adding rules.

Access Role Rights

Roles can be customized by enabling or disabling access to a specific feature, rule type or action (see Access role rights tab in Access Role Properties).

Be advised that at least one user must be always assigned to a role that holds Manage access rights permissions. The software has a built-in mechanism that protects you from locking yourself out - if you attempt to revoke Manage access rights for the only role that was assigned this permission, such action will be stopped and a warning will pop up (Fig. 3.). The same will happen if you delete the only role that holds these permissions or remove all users from all roles that Manage access rights.

Fig. 3. A warning that is displayed if you attempt to remove the only member of the Manage access rights role.

Fig. 4. Access role rights tab in Access Rights Management.

To move actions up and down on the actions list, a user must be granted permissions to edit, add and delete all action types in all already configured rules.

Access Role Rights permissions

Users that are members of the following roles are given permissions to do the following:

• Manage program administrative features
  • Access to all tabs in Settings window except for Categories (governed by Manage rules order and their General properties right), Logon Settings and Connection which are available to anyone regardless of their role membership
  • Use Import/Export feature
  • Gather diagnostic files via Help, Collect all log files
  • Open licensing window and activate the software's license
  • Change notification settings (Help, Notifications)
• Manage access rights
  • Modify Access Roles in Access Rights Management window - at least one user must be always assigned to a role that holds this permission
• Create new rules
  • Add and configure new rules
• Manage rules order and their General properties
  • Change order on the list of rules
  • Edit content of General tab of every rule
  • Manage rules categories via Settings, Rule categories tab, as well as via Category Manager available in category picker.
• Manage rules Conditions and Exceptions
  • Edit content of Conditions and Exceptions tabs in every rule
• Manage rules Actions
  • Edit content of Actions tab in every rule, can be enabled for all rights - edit, add, delete or customized:
    • Edit existing actions
      • Edit properties of already added actions - can be enabled for all actions or for selected only
    • Add actions selected above
      • Add new actions - limited to actions selected in Edit existing actions right
    • Delete actions selected above
      • Delete existing actions - limited to actions selected in Edit existing actions right
        For example, if you granted permissions Edit existing actions only for Insert disclaimer action and also added Delete actions selected above, a user will be able to edit and delete only Insert disclaimer action and nothing else.
• Manage rules Options
  • Edit content of Options tab in every rule

Access Role Rights conflicts

It is possible to add the same user to multiple Access Roles. In such scenarios permissions from different roles are added.

Note that particular Access Role Rights grant you permissions to do something, there are no rights to specifically prohibit doing something. To easily understand that assume that granted permission has value of one and the lack of it has value of zero. If a user is a member of a role that e.g. grants him rights to create new rules but is also a member of another role that does not have this right, effectively this user will be able to create new rules (value of first role for create new rules right is 1 as it is granted, value of the other role for the same right is 0 as it is not granted, their sum is therefore 1, so a user is able to create new rules). To forbid particular user from specific permission you must review Access Role Rights of all roles this user is a member of and either make sure none of those roles grants the permission in question, remove particular permission from a role if necessary or remove a user from that role.

Rules Rights

Aside from the above mentioned Access Role Rights, you can configure per rule access rights. This will be useful if, for example, you want to delegate rules management tasks to other people but do not want them to see some specific rules. You can limit their visibility in Rules rights tab.

Fig. 5. Rules rights tab in Access Rights Management.

Be advised, the order of the list of rules is always the same as of rules list in the main Administration Panel window. However, you can sort them alphabetically by clicking on Rule name column header. After closing and reopening this window, original order is restored. Also, selecting a checkbox in the header of one of the columns (View, Edit, Delete) will automatically select checkboxes below in the whole column.

When creating a new rule the software will ask which access role should be used to create this rule if more than one role has permissions to create rules. This is to establish which role should be an owner of this rule and which role's Rules rights will be applied in the future.

Fig. 6. Selecting a role that will be a rule owner.

Please note that a role, not a user, is considered an owner of a rule. A user can be a member of such a role and therefore enjoy all owner's privileges defined in the Rules rights tab. If this user creates a new rule, it will automatically be owned by a selected role (see Fig. 6.) and this role will have all rights (View, Edit, Delete) to this rule. It is not possible to limit those for rules that have not been created yet. If you remove this user from that role, the user will lose all rules rights and will inherit rules rights from whatever role he is assigned to now.

See next

Configuration of rules - this article along its subsections describes typical examples of use, how to create rules, the actions that can be applied to the processed mail, conditions and exceptions that trigger / exclude rules from triggering the actions and additional options that boost the program's functionality.

See also

Logon settings - this article describes how to define what type of authentication will be used to logon to the particular Administration Panel to access Exchange Rules Service yet configure the program