Product Documentation

{ CREATE USER: security user id = value1, security password = value2, first name = value3,
               last name = value4, email = value5, company name = value6
               [, company name = value7] [, work phone = value8]
               [, city = value9] [, state = value10] [, allow 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
• 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 rules 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. If there is an attempt to create a new user account and no licenses are available, the account is created, but is disabled
• An error is generated if the user attempts to create a duplicate or invalid security user id
• 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} && NEW_USER_ID.{not null}) {
  CREATE USER:
    security user id      = NEW_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,
    postal code           = ZIP,
    area                  = 'Questionnaire Area',
    project               = 'Questionnaire Data',
    alpha timezone        = PST8PDT,
    user_role             = ENGINEERING; SALES,
    privacy group         = PRIVACY_GROUP_LIST,
    enabled user          = N,
    allow email dups      = true,
    allow first last_dups = false
}
## Not strictly part of the CREATE USER rule, but we might now want to assign
## the user just created to another field on the form - in this case the list
## field named CONTACT
if (PROJECT='Contacts' && CONTACT.{is null} && NEW_USER_ID.{is not null}) {
    CONTACT = NEW_USER_ID;
}

Full Parameter Field List