Configuring Settings in File-Based Settings Mode

Default Values in the Software

The Version 6 software provides default values for all settings. This enables you to start a session without any settings files (for example, if settings have been deleted accidentally). End users can run a session and use the defaults.

Order of Priority

Setting files are stored in directories referenced in the Version 6 runtime environment by the CATReferenceSettingPath and CATUserSettingPath environment variables:

• CATReferenceSettingPath points to the directory (or the concatenation of directories) where administrator settings are stored. The order of the directories represents the adminstration hierachy.
• CATUserSettingPath points to the directory where user settings are stored.

When a session is started, the directories pointed to by these variables are searched in the following hierarchical order: all files found first in the CATReferenceSettingPath, and then in the CATUserSettingPath will be read in this order.

When a session is started, if no setting file is found either in the CATReferenceSettingPath or in the CATUserSettingPath, the setting value is the default provided by the software.

If settings files have been deleted, an end user will inherit the setting values set by the administrator or the default values provided by the software.

If there are administrator directories pointed to by CATReferenceSettingPath, and the settings have not been locked, the value is the value written in the last administrator's file found in CATReferenceSettingPath, or in the user file found in the CATUserSettingPath. In this case, the end user will still be able to modify the settings.

Concatenation Mechanism Involving One or More Administration Levels

The correct way to administrate the settings is to first of all build a logical view of the administration hierarchy like this:

The top-level is the Company. This level is administrered by administrator CompAdm and contains departments DepX and DepY, administered by administrators DepXAdm and DepYAdm respectively. Projects PrjA and PrjB are associated with DepX, and PrjC with DepY. User1 and User2 work on project PrjA, which is administered by administrator PrjAAdm, User3 works on PrjB which is administered by administrator PrjBAdm, and User 4 works on PrjC which is administered by administrator PrjCAdm.

The next task is to create a runtime environment file mapped to each level. In our example, zoom partially on the overall structure and concentrate on the branch containing DepX and PrjA as illustrated. The box on the right-hand side represents the runtime environment file:

Company-level administrator CompAdm creates a runtime environment file for the company level, and sets CATReferenceSettingPath to point to the directory CompRefDir.

At the department level, administrator DepXAdm creates a runtime environment file for the department level, and sets CATReferenceSettingPath to concatenate two directories, CompRefDir and DepXRefDir in that order.

Finally, project administrator PrjAAdm creates a runtime environment file for the project level then sets CATReferenceSettingPath to concatenate three directories, CompRefDir, DepXRefDir and PrjARefDir in that order.

The key concept here is the role of the runtime environment file. Running a Version 6 session executes a runtime environment file. When multi-level administration is implemented, an end user inherits the settings located in the directory (or directories) pointed to by the CATReferenceSettingPath variable of the runtime environment being executed.

Concatenating Settings Locks

If there are administrator directories pointed to by CATReferenceSettingPath, and settings have been locked, the setting value is the value written in the first administrator directory where this attribute has been locked. End users will not be able to modify the settings.

For full details about how to start a session in administrator mode for the purpose of locking settings, refer to Locking Settings.

For a fully detailed scenario illustrating how settings are concatenated and inherited, and involving multiple administration levels, refer to Detailed Scenario Illustrating Concatenation and Inheritance Mechanisms.

Different users may want to set different types of locks at different levels for a variety of reasons.

If several users set locks in different folders using the same environment, end users of the same environment will inherit all the locks set by those administrators.

To implement this solution, you must concatenate several CATReferenceSettingPath values as illustrated below:

In this example:

• one administrator (starting in administration mode) locks settings in "Environment 1" at the site level
• on the same site, two administrators (also starting in administration mode) in two different workshops lock settings in "Environment 2" and "Environment 3" respectively
• users 1 and 2 run a Version 6 session with "Environment 2" and inherit the setting locks in "Environment 1" and "Environment 2" respectively
• users 3 and 4 run a Version 6 session with "Environment 3" and inherit the setting locks in "Environment 1" and "Environment 3" respectively