You are here: Administration > Security > Restricting Access to Security Settings

Restricting Access to Security Settings

It is very important to control who has access to the security features of Proliance. Only authorized users, such as the system administrator or workspace manager, should be able to view and update the Roles, Categories, and Company Roles registers.

Access to security is controlled by the Security Permissions setting, found in the Permissions section of a security role. The following table summarizes the effects of this setting:

Permission	Effect
Create	If granted, the "New" button is available in all the security registers. If not granted, the "New" button is dimmed and unavailable in all the registers.
Delete	If granted, the "Delete" button is available in all the security registers. If not granted, the "Delete" button is dimmed and unavailable in all registers.
Read	If granted, all the security registers are visible in the Configuration submenu in either the Workspace, Program or Organization menus. If not granted, none of the registers are visible. Removing Read permission is the quickest way to disable access to the security features. Note: Read permission is required for any of the other permissions to work.
Update	If granted, any item in the security registers can be edited. If not granted, then the Edit button is disabled in all security documents.

To Restrict access to security

Edit each security role as necessary.

You should give access only to the document types required by someone holding that role to do their jobs.

Note:

Security for the Accounts page the Accounts settings in the Permissions section of a role. In order to regulate who can create and modify accounts in Proliance, you should also exercise similar caution for this document type.

Tip:

Carefully review all the roles in the Roles register to ensure that only the appropriate roles have any permissions under Security Permissions. For example, the Administrator role should have all the permissions, but the Clerical role should have none.
Alternatively, you can create new roles that specifically exclude access to security, just so there is no mistake. Excluding access to security will prevent people from tampering with the permissions by giving themselves a role to which they are not entitled.