Difference between revisions of "User Admin Tool Configuration"

From cqwiki
Jump to navigationJump to search
(Created page with "<big>'''Configuring User Administration Tool for IBM-Rational ClearQuest'''</big> The User Administration tool is extremely flexible. It allows changing the tool behavior or add...")
 
m
 
(3 intermediate revisions by the same user not shown)
Line 11: Line 11:
 
! Comments
 
! Comments
 
|-
 
|-
| admin_creds
+
| CONFIG_ADMIN_CREDS
 
|
 
|
| Yes
+
|align="center"| 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.  
 
| 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
 +
|align="center"|false
 +
|align="center"|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
 
|CONFIG_LOAD_EVERYONE_GROUP
|false
+
|align="center"|false
|No
+
|align="center"|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.  
 
|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
 
|CONFIG_MULTISITE_ENABLED
|false
+
|align="center"|false
|No
+
|align="center"|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.
 
|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
 
|CONFIG_OBEY_MS_ON_CREATE
|false
+
|align="center"|false
|No
+
|align="center"|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.
 
|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.
 
|-
 
|-
Line 35: Line 40:
 
CONFIG_PASSWORD_RESET_GROUP
 
CONFIG_PASSWORD_RESET_GROUP
 
|
 
|
|No
+
|align="center"|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).
 
|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
 
|CONFIG_GROUP_ADMIN_SUFFIX
 
|
 
|
|No
+
|align="center"|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.
 
|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
 
|CONFIG_GENERATE_PASSWORD
|false
+
|align="center"|false
|No
+
|align="center"|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).  
 
|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
 
|CONFIG_GENERATE_PASSWORD_CHARACTERS
|0-9a-zA-Z
+
|align="center"|0-9a-zA-Z
|No
+
|align="center"|No
 
|Characters used by password generator
 
|Characters used by password generator
 
|-
 
|-
 
|CONFIG_GENERATE_PASSWORD_LENGTH
 
|CONFIG_GENERATE_PASSWORD_LENGTH
|8
+
|align="center"|8
|No
+
|align="center"|No
 
|Length of the generated password
 
|Length of the generated password
 
|-
 
|-
 
|CONFIG_USER_PROFILE_FIELDS
 
|CONFIG_USER_PROFILE_FIELDS
|UserPrivileges Groups DB_Subscription_Type DB_Subscription
+
|align="center"|UserPrivileges Groups DB_Subscription_Type DB_Subscription
|No
+
|align="center"|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.
 
|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.
 
|-
 
|-
Line 71: Line 76:
 
DEFAULT_PROFILE_OPERATION
 
DEFAULT_PROFILE_OPERATION
 
|
 
|
|No
+
|align="center"|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.
 
|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
 
|CONFIG_ENABLE_CUSTOM_FIELD_VALIDATION
|false
+
|align="center"|false
|No
+
|align="center"|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.
 
|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.
 
|-
 
|-
Line 92: Line 97:
 
VALIDATE_FIELD_GROUPS
 
VALIDATE_FIELD_GROUPS
 
|
 
|
|No
+
|align="center"|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:
 
|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:
 
<source lang="perl">
 
<source lang="perl">
Line 103: Line 108:
 
|-
 
|-
 
|CONFIG_ENABLE_CUSTOM_ACTION_VALIDATION
 
|CONFIG_ENABLE_CUSTOM_ACTION_VALIDATION
|false
+
|align="center"|false
|No
+
|align="center"|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.
 
|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>
 
|VALIDATE_ACTION_<ACTION_NAME>
 
|
 
|
|No
+
|align="center"|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.
 
|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.
 
|-
 
|-
Line 115: Line 120:
 
MAX_LENGTH_PHONE
 
MAX_LENGTH_PHONE
 
MAX_LENGTH_EMAIL
 
MAX_LENGTH_EMAIL
| 50
+
|align="center"| 50
| No
+
|align="center"| 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.
 
| 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.
 
|-  
 
|-  
Line 122: Line 127:
  
  
[[Category:User_Admin_Tool]]
+
 
 +
[[Category:Rational]] [[Category:User_Admin_Tool]]

Latest revision as of 14:41, 1 February 2013

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!";
  }
Please note that DB subscription and type properties are the same for both Group and User record types. You can check record type within the custom hook using
$entity->GetEntityDefName()
API call.
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.