Maintaining Users

• Maintaining Users
  • Overview
  • Process
    • Licencing
    • Creating Users
      • Example Scenarios
    • Updating Users
      • User Roles
      • User Languages
    • Deleting Users

Overview

A user is someone who, or a service that, can log into the system and access applications and entities.

A user can also have a principal name used for AAD authentication, a menu that is used to navigate CCLAS applications, photo and signature images, salutation and naming details, contact and address details, work details, signatory text, multiple security profiles and a list of active system languages which are a sub-set of the system languages that are active at the system level.

Calls to SOAP services apply case insensitivity to a user code for authentication.

A security profile comprises the role name and laboratory scope. Each role name has access and security rights assigned to it. The accumulated security roles are used, along with the system menu, to navigate through the CCLAS functions and applications.

Various fields in CCLAS can be linked to a user:

• A field in an audit record that contains the user who changed the state of an entity, resulting in the audit record being written.
• A field on an entity to indicate that an action is undertaken by the user.
• A value of a user or user role preference that contains the user applicable to the preference.

A user can be assigned as an owner of a job or sample, or can be assigned to a cost centre so that a job's owner can be set from the cost centre when the job is linked to the cost centre.

Users can be made members of various user groups which can then be assigned to entities, such as sections, to assist the securing of functionality and scope within the system.

Process

Users are created using the CCUSER—User application and exist at instance-level, that is, above organisations and laboratories.

Maintain users

Upon maintaining users:

• The event is audited.

Users can be created from scratch or from an existing user. When a user is saved as another user, the source user's security roles and language settings are copied so that the destination user is granted the same rights and system languages as the source user.

A user can be configured with a Principal User Name for AAD authentication. Refer to Configuring AAD Authentication.

Language settings are set in the user-level msesys.config.multivaluedI18Nsetting system user preference, visible in the MSEPRF—User Preferences application as a text field containing the active system languages for the user, and visible in the MSESYS—System Preferences application for the user (however, since this application allows any text to be entered as the preference value, care must be taken when setting it up this way).

Searched users can be exported to a report. Available report templates are defined in the SEARCH_REPORT_CCUSER application preference. Refer to Generating Grid Reports.

Licencing

When an attempt is made to add a user with an active security role to the system, or to save a user that has an active security role as another user, or to add a security role (default active) to a user who currently has no active security roles, then the environment's licence key is checked to determine whether the user role can be added.

• If there is no licence key in the table, then an error is raised: CCLAS Licence is not available. Contact LIMS Manager for Licence Update.

• If there is a licence key in the table but the licence key is expired, then an error is raised: CCLAS Licence has expired on <ExpiryDate>. Contact LIMS Manager for Licence Update.

• If there is a licence key in the table but the licence user count is reached or exceeded, then an error is raised: Licenced Users count exceeds the Licence Count of <MaxUserCount>. Contact LIMS Manager for Licence Update.

This also applies when Maintaining Security Roles and an attempt is made to add an active security role to a user.

Creating Users

See Maintain users for more information on the steps on creating users.

An application preference (DEFAULT_ROLES_FOR_NEW_USERS) is available to enhance creation of users. The value of the preference follows this syntax:

• Role Name:Lab Code
  1. Role Name - is a valid Role Name from MSESEC
  2. Labcode - is a valid Lab code from CCLBRT
• Role Name01:Lab Code,Role Name02:Lab Code... (If multiple roles are to be assigned for new users as default)

You can assign any user in MSESEC into the preference except for SYSTEM ADMINISTRATOR role. This role gives the user total access to the system and is not intended to be an actual user role. If you assign a preference role and the labcode you want to apply the role, when you create a new user for that laboratory, the create new user service will look up the applicable preference and check on the value stored. If it finds a valid preference and labcode, then it will create a user with the role inherited from the preference of that lab.

If the preference value is incorrect or if you assign SYSTEM ADMINISTRATOR as a default value in the preference then the following error messages will appear in CCUSER when you create a user:

Error Message	Description
2000.E00362: Cannot create User [User Code] with defined Roles.	General error message that the user has not been created. The User Code in the error message is the intended user code for the new user.
1010.E0003: Failed to assign user [User Code] to role [Role Name] in scope [Lab Code]	Specific error message that the user code has not been created. This might be due to role name being incorrect or the laboratory code is incorrect.
1010.E0056: Scope cannot be specified for SYSTEM ADMINISTRATOR role.	Specific error message that the SYSTEM ADMINISTRATOR role cannot be assigned as a value in the preference.

Example Scenarios

Some scenarios of how the preference can be applied.

• Assign a default role for new users. This is the most common use case. The default role does not have to have any rights but by attaching the user to a "default role" is sufficient enough for LIMS user administrators to use MSESEC (security roles application), find this new user in the list of users to be assigned laboratory roles for their true role assignments. This can be defined as a laboratory preference (Lab scope) most likely. It can be maintained as an organisational preference (Org scope) if the LIMS administrators want to maintain this across all the labs under the same Org by using the asterisk (*) in place of the real lab code. To fulfil this scenario, the preference must be present, active and have a value following the syntax Role Name:Lab Code, where the Role Name is a valid role followed by a colon symbol then the laboratory code which is an active laboratory(ex. FRONT_DESK:LAB_A). Once the user is created, the role assigned in the preference will be assigned to the user for the laboratory defined.
• Assign multiple roles for new users. This is not a common scenario but shows what the preference is capable of doing. Multiple roles can be assigned to new users by comma separating each Role Name:Lab Code combination (ex. FRONT_DESK:LAB_A,QA_MGR:LAB_A). This would assign multiple roles to the new user under the laboratory code defined. Once again, this is not a common scenario but the option is available if used.

Note: The DEFAULT_ROLES_FOR_NEW_USERS preference only applies when creating new users from the Create service in CCUSER. This does not apply to a user created from a "Save As" from another user as the rules for this method has already been defined as copy from the source.

Updating Users

Where a Menu Name is not defined for a user, then the default menu, GM—CCLAS (Global Menu), is made available to the user. A menu update is applied after the user logs in again.

All users are defined with various security roles that they can use. The security role is used, along with the system menu to navigate through the CCLAS applications.

Note: You need to restart an application for security changes to have an effect.

On update, if the Full Name is left empty, it is updated to a concatenation of the First Name, space character, and Last Name.

User Roles

Where a user is given a particular Role Name for a given Scope, the user log into the associated laboratory. Where more than one role is given for a particular laboratory, the user has a sum of all rights that are associated with each role and laboratory. if a user has no roles for a laboratory, then they cannot log into that laboratory.

Note: The SYSTEM ADMINISTRATOR user gives all rights across all laboratories. A scope of * gives the rights for the nominated role across all laboratories.

Suspending a user disables the user from logging into the laboratory denoted by the scope. This prohibits a user who no longer works at the laboratory from logging into the laboratory, but any entity that links to the user can still link to the user (for example, there is no need to change corporate active directory links or corporate logins). Where a user is suspended for all laboratories, they cannot log into the LIMS at all.

Note: A user cannot suspend the System Administrator account, nor themselves.

Changes made to security roles are applied after the user logs in again.

Examples of applying user roles:

1. The following users are not suspended for the given global or laboratory roles:
   • User A—SYSTEM_ADMIN and LIMS_MGR
   • User B—SYSTEM_ADMIN
   • User C—LIMS_MGR and SYSMGR
   • User D—SYSTEM_ADMIN, LIMS_MGR and SYSMGR

   When user A logs in and uses this activity to suspend user A, B, C and D, then:

   • No roles are suspended for user A and the system returns the message: "You are not allowed to suspend yourself from any role."
   • The system returns the message: "System Administrator [User B] cannot be suspended."
   • The system returns the message: "Action successfully completed." for User C.
   • The non-system administration roles are suspended for user D, and the system returns the message: "System Administrator [User D] cannot be suspended."
2. The following users are not suspended for the given global or laboratory roles:
   • User A—SYSTEM_ADMIN and LIMS_MGR
   • User B—SYSTEM_ADMIN

   When user A logs in and uses this activity to suspend user A and B, then:

   • Then no roles are suspended for user A and the system returns the message: "You are not allowed to suspend yourself from any role."
   • The system returns the message: "System Administrator [User B] cannot be suspended."

User Languages

Where a language code is added for a user, but the language code is not configured for the system or is not activated for all users, then it is ignored for the user.

System languages are configured in the DLAN table code of the system table. Only those system languages that are active at the system-level can be activated for a user.

The system languages assigned to a user are persisted as a dI18Nsetting system user preference, visible in the MSEPRF—User Preferences application as a text field containing the active system languages for the user, and in the Displayable Languages tab of the MSESYS—System Preferences application for the user. When a system language is added to a user, if a record if not located in the system user preference table for the preference name, user-scope for the same user, and an empty Counter, then the record is created.

Each activated language is available for use at the next login or change of user credentials, for the selected user.

Deleting Users

When a user is deleted, the user-level msesys.config.multivaluedI18Nsetting system user preference is deleted for the user, initially visible in the MSEPRF—User Preferences application as a text field containing the active system languages for the user, and visible in the MSESYS—System Preferences application for the user. The user can be deleted if there are no relevant records created by the user.