Product Documentation

{UPDATE USER: security user id = value1, security password = value2,
              first name = value3, last name = value4, email = value5,
              company name = value6 [, login id = value8]
              [, work phone = value9] [, city = value10]
              [, state = value11] [, alllow email dups = true | false]
              [, allow first last dups = true | false] [, other_fields = valuenn] }

• A full list of the fields that may be used as parameters in the command is in the section at the end of this page titled Full Field List
• The security user id is typically the name of the field that contains the existing User Id
• Field values from the current issue being inserted or updated can be substituted for any of the valuen entries.  For example, first name = VENDOR_FIRST_NAME
• You can assign a field value from a linked record to the field on the account record.  For example, company name = (parentRecordLink).VENDOR_NAME will assign the company name of the user being created to the vendor name in the link to the parent record named parentRecordLink
• You may assign a string value to a field.  For example, area = 'Customer Account' sets the value for the user's area.  Of course, the value for the field must exist
• Both the roles and privacy_group parameters may be multi-valued.  In that case the values are separated by semi-colons.  For example user role = ENGINEERING; MARKETING; ACCOUNTING will assign these 3 roles to the user being created
• It is recommended that this feature be used to create users in a guest role capacity, or more explicitly, to be in the role nominated in the behavior setting named LIMITED_USER_ROLE
• A further recommendation is that you use this command to create users who occupy concurrent licenses as opposed to named licenses.  This avoids the potential to attempt to create a named user license when no more are avaiable.  An error is generated if there is an attempt to create a new license and none are available
• The security user id = value1 parameter is required as this specifies the user record to be updated.  You may map the login id to a new value as long as the security user id is provided
• allow email dups - When this is set to a value of true, then duplicate email addresses will be allowed across different users.  The default is false.  Care should be taken when assigning this to a value of true, as it will not be possible to determine which user is creating an issue via EVMail, as this is dependent upon the software finding a unique email address within the ExtraView application.  The default value is false
• allow first last dups - When this is set to a value of true, then duplicate combinations of first and last names are allowed with different users.  The default value is false
• This action is often used as a companion to the <== user mapping ==> directive which allows administrative changes to users to be reflected in updates to issues which were originally used to create user information.

Note

It is recommended that you use a built-in JavaScript function to verify the password before the rule is invoked.  To achieve this, configure the following:

• A text field to store the password.   This field is passed to the server as part of the CREATE USER rule in the security_password parameter
• A text field to store the verify password field.  This field is not passed to the server, but you should place a layout cell attribute of the type HTML MODIFIER on the field.  The syntax of the value is:

  onchange=checkPasswordRules(p_passwordfield.value, p_verifypassword.value, minCharacters, minNumeric, minUpperCase, minSpecialChars)

  passwordfield - the name of the password field on the form
  verifypassword - the name of the verify password field on the form
  minCharacters - the minimum number of characters in the password
  minNumeric - the minimum number of numeric characters in the password
  minUpperCase - the minimum number of upper case characters in the password
  minSpecialChars - the minimum number of special characters in the password

  The 4 digits should be identical to those in the behavior setting named PASSWORD_RULES

• An example might be onchange=checkPasswordRules(p_password.value, p_verifypass.value, 8, 1, 1, 1)

Example

if (PROJECT=Contacts && CREATE_USER_BTN.{changed} && USER_ID.{not null}) {
  UPDATE USER:
    security user id      = USER_ID,
    security password     = 'Welcome',
    first name            = VENDOR_FNAME,
    last name             = VENDOR_LNAME,
    email                 = VENDOR_EMAIL,
    company name          = (parentRecord).VENDOR_LIST,
    work phone            = VENDOR_PHONE,
    city                  = CITY,
    state                 = STATE,
    zip                   = ZIP,
    area                  = 'Questionnaire Area',
    project               = 'Questionnaire Data',
    alphap timezone       = PST8PDT,
    user role             = ENGINEERING; SALES,
    privacy group         = PRIVACY_GROUP_LIST,
    enabled user          = N,
    allow email dups      = true,
    allow first last dups = false
}

Full Field List