There are two SDMS roles that affect user access to SDMS documents and other SDMS elements. These are Administrator and Everyone. Typically you would not change the Administrator and Everyone role-based permissions after they are set up for your facility. Doing so can alter access to documents and other elements in SDMS in a way that is not intended. It is recommended that you make changes only after consulting a permissions design chart applicable to your system and determining how changes will affect it.
TIP Roles apply to all sites.
>> To view the permissions configured for roles
| 1. | Log on as a user with access to open Utilities > SDMS Admin and click the Permissions tab. |
| 2. | Highlight the Administrator or Everyone role for which you want to view permissions, and then click Edit. |
| 3. | In the resulting dialog box, in the Administrative permissions tab, double-click the SDMS entity for which you want to view permissions. |
>> To configure permissions for roles
| 1. | If you do not already have the role configuration dialog box open, perform steps 1 to 3 in the prior procedure. |
| 2. | The dialog box displays two tabs, Administrative permissions and Global permissions. |
IMPORTANT It is recommended that changes be made only after consulting the overall system permissions design to determine their impact.
In Global permissions:
| • | For the Administrator, it is typical to set Allow for all global permissions within SDMS, such as Create sites. In particular, without Allow access for Create sites, Create groups, Create users, and Create projects, STARLIMS cannot properly synchronize with SDMS when sites, teams, users, and client projects are added in STARLIMS and their SDMS permissions are set. |
| • | For Everyone, it is typical to leave almost everything as <inherited>, which is the same as <not set> in other application windows. Then you can use Deny or Allow to fine-tune permissions for file types, flags, or projects. The default setting for Everyone in the system is unset for everything except Document, for which access is allowed during workflows. As a result, all users have at least limited access to documents. |
| 3. | In the Administrative permissions tab: |
| • | The same SDMS types for which you can configure document permissions in other application windows appear here, such as Project. |
TIP In this tab, the Document Types category is the same as File Types in other application windows.
| • | Additionally, access is controlled for other SDMS categories, such as Document Unified XML, which are not related to document permissions. Thus, you will not see the Document Access column populated for these SDMS Types. |
Double-click the SDMS entity for which you want to view/configure permissions.
| 4. | In the resulting dialog box there are two tabs (for most entities, for some only the first one): |
| • | Administrative permissions - For a selected SDMS entity such as Project, use this tab to Deny, Allow, or <not set> access to browse, edit, delete, deep delete (shred), change content, change owner, or change permissions to the SDMS entity. |
| • | Document access permissions - Use to provide permissions to documents within an available SDMS entity such as Projects. These permissions correspond to actions available in the Incoming Queues or Documents applications. They include browse, read, modify (called write elsewhere), delete, deep delete (called shred elsewhere), change document location, attach to workflow, and sign document. |
After you click OK to commit changes, the Role Configurator dialog box displays:
| • | A (Allow) |
| • | D (Deny) |
| • | "-" (not set) |
These settings appear under the Document access and Administrative access columns according to the permissions configured in the entity configuration dialog box. For information, see the prior two sections Permissions and Configuring User Permissions.
A few additional facts concerning roles
The SDMS Administrator, that is the user who has the Method Developer privilege marked in the User Management application, is affected by both the Administrator and Everyone roles, so setting Deny anywhere in the Everyone role can limit the Administrator as well. Do not change the Everyone and Administrator roles without careful consideration. Other roles may appear in the Permissions application window such as Owner, Restrictor, Creator, and a series of roles with a "_" prefix. These roles are strictly for system use and should never be changed.