Configuring Access to CCLAS Applications, Tables and Fields
Overview
For each staff account, access to CCLAS EL applications, tables and fields is configured using staff program settings.
Staff access levels define the level of access that a staff member has to CCLAS EL applications and tables.
Staff accounts for general CCLAS EL staff members are associated with staff roles so that access levels to CCLAS EL applications and tables, and program settings, are inherited from the role.
This process is pertinent to LIMS configuration personnel and laboratory managers who configure user accounts for CCLAS.
Process
Access to CCLAS EL applications and tables is controlled by the specific AccessLevel program setting for the relevant application or table node. Access level program settings cannot be deleted.
Program settings are settings that apply to individual CCLAS EL applications, or for nodes within a program. These settings are stored under the CCLASMGR staff account. Where a program setting is defined for a staff account, this setting overrides that set on the CCLASMGR staff account. Where a program setting is defined for a staff role, for a user that does not have the staff setting defined for their account, but the user has the staff role, then this setting overrides that set on the CCLASMGR staff account. Custom program settings can be defined and are called user settings.
The following access levels are available:
- -1—Access permissions are inherited from the role associated with the staff account.
- 0—No access is given to the data records or application.
- 1—Read-only access is given to the data records or application.
- 2—Read-write access is given to the data records or application, and the staff member has the ability to temporarily modify properties by using the right-mouse button to open the Properties form, but cannot save the changes except for the CCLAS EL menu window size and position.
- 3—Read-write-delete access is given to the data records or application, and the staff member has the ability to modify properties by using the right-mouse button to open the Properties form, and can save the changes to the CCLAS initialisation file, and make changes to other menu files.
Examples:
- Where a CCLAS application writes to the Profile tables, then the AccessLevel Program Settings - PROFILEAPP must be at least 2 for the staff account.
- Where a staff account is set up to for a balance operator in which read-write access is required to the Data Entry application, then the AccessLevel Program Settings - MDE must be at least 2 for the staff account. However, where the UpdateJobStatus Program Settings - MDE is disabled, when the spreadsheet data is saved, it updates the various levels of date started in the job but does not update all the minor statuses. To update the minor statuses as well, the AccessLevel Program Settings - PROFILEAPP must be at lease 2 for the staff account.
Access levels control access to the following resources and nodes within CCLAS applications:
For example, to configure user access to the Data Entry application, set the AccessLevel Program Settings - MDE.
Staff access levels are taken from the staff account and not from the staff role settings.
Maintain access levels to CCLAS entities for a staff account
Specific fields in the following tables can be marked as read-only for a staff account, regardless of the CCLAS EL application used to display them:
- Scheme
- Scheme_Analyte
- Scheme_Refer
- ProcReg
- ProcReg_Scheme
- ProcReg_Scheme_Analyte
- Client
- Client_Contact
- Client_Project
The field protection configuration is a positive restriction mechanism, that is, it positively defines those fields that a staff account cannot change. I these fields are set up for the CCLASMGR staff account, then everyone in the laboratory will only have read-only access to these fields.
Note: Where a particular field must be read-write for some staff members but read-only for other staff members, then all the staff members that require read-only access need to have data protection records created for their staff accounts.
Along with staff roles, the field protection mechanism allows for the protection of a specific field at either the staff account or the staff role level. If a field is restricted at the staff role level, the field can be made read-write at the staff level, if required.
Field protection is not inherited from the CCLASMGR staff account. However, if a staff account has a staff role defined, the field protection defined for the staff role is inherited by the staff account.
