Open topic with left hand navigation

About Security Roles

A security role defines a set of permissions to specific features in Proliance. Everyone holding that role has the same security access to a feature. A user may hold multiple roles, in which case the permissions from the roles are cumulative. The more permissive role will take precedence over the other one.

ClosedExample

John has been assigned the Client and Superintendent role. The Client role enables him to create RFIs. The Superintendent role does not enable him to create RFIs. The Client role will take precedence over the Superintendent role, hence, John is able to create RFIs.

Security roles and their permissions can be different between work areas. For example, permissions to catalog cards for the 'Designer' role in the Organization work area may differ from the permissions for the same role in a portfolio. The permissions that take effect depend on the user's current location.

Permission for uploading and downloading files in catalog cards is controlled in Proliance Local Admin. For more information, see "Editing File Upload/Download Roles" in the Proliance Local Admin on-line help system.

State Read-Only Fields Security Roles

Prior to Proliance 4.0, several fields in documents were locked depending on their current workflow state (i.e., they were editable in some states but not in others). During the Proliance 4.0 upgrade, new security roles (State Read-Only Fields - <document>) were automatically created. Users who are assigned these roles can now edit these document fields in any workflow state. For example, to grant users permission to edit a contract in any state, assign them the "State Read-Only Fields - Contract" role. Note that these roles do not have other security permissions and are only available for existing workspaces. New workspaces (unless they are created by copying an existing one) will not require these roles as these previously state-dependent fields will now be editable at any time.

These field-level security settings are overridden by the Update All Fields permission for a given document type. If you are assigning a user to one of these roles, ensure that the other security roles that the user may already be assigned to does not have the Update All Fields permission for the given document type selected. Example:Closed

Important: If you choose to retain the pre-Proliance 4.0 state-dependent fields feature for your existing workspaces, you can continue to do so. However, you need to ensure that the Update All Fields permission for a given document type is not selected in the security roles. For more information, see "Assigning Permissions to a Role".

A security role has the following sections under the Main area:

ClosedGeneral

ClosedPermissions

This section describes the security permissions for each document type for the role.

Enter the edit mode to make changes. For more information, see "About Security Permissions".

 To open a security role

  1. Open the Roles register.
  2. Select the security role to open.

When you edit portfolio and workspace level roles, a page link appears for the respective area beside the "Main" page. In read only mode, the check boxes are disabled. When you click Edit, you can do the following:

Tip:

  • To safeguard your data, create a security role that has no permissions to the Security Permissions setting, or remove this permission from the appropriate predefined roles. For more information, see "Restricting Access to Security".
  • The "Add Contacts" role enables you to add contacts to workspaces.

Note:

  • Permissions in a security role complement the permissions in a user's company role, with the more "permissive" permission being used. For example, if the security role allows the updating of contracts, while the user's company role does not, then the user will be able to update contracts.
  • Security roles can be grouped in security categories.