Maintaining Application Preferences

A preference is an application setting used to allow business logic to be adjusted based on a real-time assessment of what options are available to be applied.

For example, a preference might be used to allow a specific business logic to occur or not, based upon whom has logged in and for which laboratory or organisation.

Application preferences are used to:

  • Permit or deny access to functionality
  • Set defaults for fields
  • Set default form content.

Application preferences do not define the actual logic, but whether it is processed or not.

Preference Scope

Application preferences are created at instance-level. An instance contains multiple application preferences.

Application preferences have a scope that defines the business logic options at any of the following hierarchy levels: INSTANCE, ORGANISATION, LABORATORY, ROLE, USER, USER-ROLE.

Use of Preferences

The business logic in the various CCLAS applications applies the setting from the lowest permitted Scope at which it exists, that is, where the application preference's Is Lowest Level Lock is selected. For each Scope level:

  • INSTANCE—Where there is no lower level application preference than this INSTANCE application preference, or the preference's Is Lowest Level Lock is selected, and the user's first security role (sorted ascending alpha-numerically) is any security role, when a user logs into a laboratory, then the INSTANCE scope application preference applies.
  • ORGANISATION—Where there is no lower level application preference than this ORGANISATION application preference, or the preference's Is Lowest Level Lock is selected, and a user's first security role (sorted ascending alpha-numerically) is any role, when the user logs into a laboratory associated with the preference's organisation, then the ORGANISATION scope application preference applies.
  • LABORATORY—Where there is no lower level application preference than the LABORATORY application preference, or the preference's Is Lowest Level Lock is selected, and a user's first security role (sorted ascending alpha-numerically) is any role, when the user logs into the laboratory associated with the preference's laboratory, then the LABORATORY scope application preference applies.
  • ROLE—Where there is no lower level application preference than the ROLE application preference, or the preference's Is Lowest Level Lock is selected, and a user's first security role (sorted ascending alpha-numerically) matches the preference's Role Name, when the user logs into a laboratory, then the ROLE scope application preference applies. This can be sub-assigned to a specific application by setting the preference's Application Code, if required.
  • USER—Where there is no lower level application preference than the USER preference, or the preference's Is Lowest Level Lock is selected, when the user logs into a laboratory, then the USER scope application preference applies. This can be sub-assigned to a specific application by setting the preference's Application Code, if required.
  • USER-ROLE—When the current user logs into a laboratory, and the user's first role (sorted ascending alpha-numerically) matches the preference's Role Name, then the USER-ROLE scope application preference applies. This can be sub-assigned to a specific application by setting the preference's Application Code, if required.

Where a user has multiple security roles, preferences with a Scope of ROLE or USER-ROLE are sorted (ascending alpha-numerically), by the user security's Role Name and the first application preference returned.

Application preference properties that are required, by scope:

Scope Org Id required? Lab Id required? User required? Role required? Application Code required? Can have category?

Instance

N

N

N

N

Optional

N

Org

Y

N

N

N

Optional

Y Org-scope only

Lab

N

Y

N

N

Optional

Y

Role

N

Y

N

Y

Optional

Y

User

N

Y

Y

N

Optional

Y

User-Role

N

Y

Y

Y

Optional

Y

The processing logic used to return the appropriate preference's Setting Value is as follows:

  • Get each preference's Setting Value for the matching preference's Preference Name, sorted by the scope hierarchy above, and where the application preference matches the search criteria.
  • For these application preferences, determine the lowest scope that contains an application preference where the preference's Is Lowest Level Lock is selected. If no application preference has the Is Lowest Level Lock check box checked, then find the lowest scoped set of application preferences.
  • If the scope of the set of application preferences is "Role" or "User-Role" return the first application preference in the list (sorted ascending by Role Name). Any other set of application preferences contains only a single application preference, so return that.

Again, as stated above, for the Role and User-Role scopes then the first application preference in the set of application preferences is returned (first application preference sorted ascending by Role Name). In this case, it is possible for Role scoped, "Preference2" to be locked, but the role scoped application preference "Preference1" to be returned.

Core Application Preferences versus User Defined Application Preferences

Core application preferences are those that the CCLAS applications know about, and how to react to their values.

User-defined application preferences are those that a particular site has set up. These application preferences typically are utilised within scripts to select various logic pathways through the script execution. The CCLAS applications do not know how to react to these application preferences.

Application Preference Types

Currently there is no difference as to whether Preference Type is SECURITY or PREFERENCE. At this stage, this field can be used as an internal separation for searching or editing choices.

System Application Preferences

System application preferences are those preferences that are flagged as such by either the default deployment or by the system manager.

A system application preference is not so much a mandatory application preference that the CCLAS applications must know about, but effectively it is a way for the system manager to effectively 'lock for change' a particular application preference.

It is up to the system manager to determine who can run any of the application preference methods (for example, Search. Create, Read, Update, Delete, SaveAs, Fetch), and if a User can run the Update method, whether the Is System property is read-write, or even on the Detail form of the CCPREF—Preference application.

Restrictions on Updating Application Preferences

Once an application preference has Is System checked then it cannot be deleted, or copied or its content/values changed. The only property that can be changed for an application preference that has Is System checked is the Is System property itself. Once (and only if allowed via Security rights) Is System is changed (and submitted), other properties of the application preference can be changed.

Note: When any preference is updated, the preference changes may not take immediate effect due to the PREFERENCE_CACHE_EXPIRY_INTERVAL_IN_MINUTE application preference.