User Admin Tool Configuration
Configuring User Administration Tool for IBM-Rational ClearQuest
The User Administration tool is extremely flexible. It allows changing the tool behavior or adding customizations, such as setting field default values or adding enhanced field or action validation, without schema modification. Its configuration is stored in the ClearQuest database using udb_property records. These records are protected using Security Context feature and not visible to regular users. In addition, the most critical data is encrypted.
You can find currently set property values in the public workspace query "Public Queries\Database_Settings\Properties".
Property Name | Default Value | Secure | Comments |
---|---|---|---|
CONFIG_ADMIN_CREDS | Yes | It is a "secure" property that carries administrative user credentials in username/password format. This user account is used to communicate to the master user repository to query or sync users and groups. | |
CONFIG_AUTO_DB_UPGRADE | false | No | By default, the User Admin tool operates in the same way as the standard user administration utility: you create and/or modify users and group, and then you have to execute "Upgrade_User_DBs" action to push changes into user databases. Setting this property to non-zero value would force database upgrade every time you save User or Group. Depending on size of your environment (number of users and user databases, database server, etc), there might be some performance drawbacks. If it does not work well for you, you can always switch back to the default procedure by setting this property to zero (or deleting it + logout/login). |
CONFIG_LOAD_EVERYONE_GROUP | false | No | A built-in "Everyone" group was introduced with ClearQuest Feature Level 7. This group cannot be modified, and by default, it is not loaded to the User Administration tool. This behavior can be changed by setting this property to non-zero value. There is no reason to lad built-in "Everyone" group, but if you are using pre-FL7 database that has group with this name, it might be a solution. |
CONFIG_MULTISITE_ENABLED | false | No | Enables Multisite resource-consuming validations, such as mastership of the groups that you would like to add user to. It might impact performance. Do not set it, unless you are using the tool in multisited environment and you are planning to use the tool from many sites simultaniously. |
CONFIG_OBEY_MS_ON_CREATE | false | No | By default, during initial load and synchronizations, all users are loaded into the database regardless of mastership. This behavior can be changed by setting the property to non-zero value. In this case, the load will be limited to locally mastered users and groups, but it will require you to perform load from each site. |
CONFIG_SUPER_USER_GROUP
CONFIG_USER_ADMIN_GROUP CONFIG_PASSWORD_RESET_GROUP |
No | By default, ClearQuest user with Super User or User Admin privilege is allowed to create and update users and groups, and Super User only is allowed to delete user or group records (when no associated account exists in the master repository). It can be changed by setting the corresponding property to ClearQuest group name. Members of the group would carry the privilege withing the tool, but they would not be able to use the standard ClearQuest user administration utility (to avoid possible problems and necessity of synchronization). Members of the group set in the CONFIG_PASSWORD_RESET_GROUP are allowed to reset user's password only (execute "Password_Reset" action). | |
CONFIG_GROUP_ADMIN_SUFFIX | No | You can use this property to permit some users to administer specific groups only (add or remove existing users and groups). For instance, by setting this property to "_ADM", you would allow members of Some_Group_Name_ADM to administer Some_Group_Name ClearQuest group without granting them any other permissions. | |
CONFIG_GENERATE_PASSWORD | false | No | When this property is set to non-zero value, and you create user account with ClearQuest authentication leaving password blank, the system will generate random password and include it in the user notification (it is kept in the "NEW_USER_PASSWORD" property). |
CONFIG_GENERATE_PASSWORD_CHARACTERS | 0-9a-zA-Z | No | Characters used by password generator |
CONFIG_GENERATE_PASSWORD_LENGTH | 8 | No | Length of the generated password |
CONFIG_USER_PROFILE_FIELDS | UserPrivileges Groups DB_Subscription_Type DB_Subscription | No | User account can be updated using other account as a profile. For example, you can create a user that would mirror access somebody else user account permissions. By default, the other user account User Privileges, Groups, Database subscription type and subscribed databases are copied, but it can be changed by setting CONFIG_USER_PROFILE_FIELDS property with desired set of fields in one-field-per-line format. |
DEFAULT_USERPRIVILEGES
DEFAULT_AUTHTYPE DEFAULT_DB_SUBSCRIPTION_TYPE DEFAULT_DB_SUBSCRIPTION DEFAULT_GROUPS_REQUESTED DEFAULT_PROFILE_CHOICE DEFAULT_PROFILE_OPERATION |
No | These properties allow to configure user and group default field values. When you start creating new user, it can be initialized with LDAP authentication type, specific set of user privileges, and be subscribed to specific set of user databases. | |
CONFIG_ENABLE_CUSTOM_FIELD_VALIDATION | false | No | This property enables check for custom field validation scripts (described later). Setting it to non-zero value enables validation scripts. When property does not exist or set to zero, custom validation scripts are disabled. |
VALIDATE_FIELD_NAME
VALIDATE_FIELD_LOGIN_NAME VALIDATE_FIELD_FULLNAME VALIDATE_FIELD_PHONE VALIDATE_FIELD_EMAIL VALIDATE_FIELD_USERPRIVILEGES VALIDATE_FIELD_PASSWORD VALIDATE_FIELD_DB_SUBSCRIPTION_TYPE VALIDATE_FIELD_DB_SUBSCRIPTION VALIDATE_FIELD_GROUPS_REQUESTED VALIDATE_FIELD_USERS VALIDATE_FIELD_GROUPS |
No | These properties can contain custom validation hook code for User and Group record fields. There is no need to define all of them when custom validation is enabled. You can define required scripts only. The script is the same as a validation Perl hook: it can use $session and $entity global variables and entire CQPerl API. In case of validation error, $result variable needs to be set with validation error message. You can take VALIDATE_FIELD_EMAIL property as an example. It checks that user's email address was provided in correct format:
my $email = $entity->GetFieldValue($fieldname)->GetValue();
if( $email !~ /^[\w\-\.]+\@[\w\-\.]+$/){
$result = "Email address needs to be specified in email\@mycompany.com format!";
}
$entity->GetEntityDefName()
| |
CONFIG_ENABLE_CUSTOM_ACTION_VALIDATION | false | No | This property enables check for custom action validation scripts (described later). Setting it to non-zero value enables validation scripts. When property does not exist or set to zero, custom validation scripts are disabled. |
VALIDATE_ACTION_<ACTION_NAME> | No | These properties contains custom validation code. Custom validation can be written in Perl, using CQPerl API and $session and $entity global variables. Error message should be assigned to the $result variable. | |
MAX_LENGTH_FULLNAME
MAX_LENGTH_PHONE MAX_LENGTH_EMAIL |
50 | No | Currently, ClearQuest user full name, phone and email fields are limited to 50 characters. If the limit is changed in the future releases, this property can be set to indicate the new limit. |