Operator ID form
Completing the Advanced tab

Field

Description

Change Password

Click to enter the user's password. After a user is authenticated, the user can change this password from the profile display.

The settings for passwords — -minimum length, number and types of characters required, whether you can re-use an old password, and so on--are set on the Security Policies landing page tab of the System landing page. Only operators with an access group including the privilege pzViewAuthPoliciesLP can see or work with the Security Policies landing page tab. For an example, see PDN article 26428 How to configure login security and password policies.

Depending on the enabled Security Policies, you may see and have to respond to a CAPTCHA test when changing a password.

PRPC records any log-in failure from any requestor type as an instance of the Log-SecurityAudit class. To view the date and time, remote host name and IP address, and user name of log-in failures, execute the standard list view rule ListofLoginFailures.

The system converts the password to a hash value using a one-way SHA-1 algorithm. The hashed value is also contained within the Storage Stream (BLOB) column of the pr_operators table. Using the RuleData toolbar button (), developers can only discover the hashed form of any operator password. The clear-text form of the password does not appear in the PegaRULES database and is never transmitted in any HTTP message to or from the workstation.

As a security feature, the passwords for [email protected] and three other initial Operator IDs can be changed only by logging in as one of the four. As a best practice, log into [email protected] and change these four passwords to private, secure values promptly after your system is installed. Repeat after any PRPC upgrade, as your passwords are overwritten by the upgrade processing. See Atlas — Initial Operator IDs.

External Authentication

Select to require that this operator be authenticated only through LDAP or other external authentication facilities. If this checkbox is not selected, the system uses the password on this tab to authenticate this operator.

Allow Rule
Check out

Select to allow this user to update rules in RuleSets that require check out.

When this box is selected, the Check In () and Check Out () toolbar buttons appear rather than the Save () button, for RuleSets that require check-out. In addition, this user has a personal RuleSet that appears at the top of the RuleSet list. See rule management facility.

Note the following:

• When check-out is enabled, the system saves the entire previous rule each time you check in a new one, supporting the Restore () operation. See How to restore the earlier state of a rule.
• Check this box for most users of the Designer Studio, even if they do not expect to check out rules. Clear this box for workers, managers, and anyone who does not use the Designer Studio or does not update rules.
• Check this checkbox for developers who plan to use the Application Accelerator to generate applications. When the accelerator generates an application, the generated RuleSets are set to require check out.
• If this box was checked, and is unchecked at a time when the operator's personal RuleSet contains one or more checked-out rules, you cannot save the Operator ID form. This restriction prevents the creation of orphaned rules — rules that are checked out but cannot be checked in. Have the operator check in or delete all checked-out rules from the personal RuleSet before clearing the box. Select > Application > Development> Checked Out Rules, or select the Show Checked Out icon () in the Quick Launch bar to display a list of checked-out rules.

For best performance on a production system, minimize the number of distinct users who can check out rules. Even when a personal RuleSet is empty  — the operator has not checked out any rules  — each user who has this capability has a unique, distinct RuleSet list. So, each Java-based rule that this user executes is assembled. Processing resources are required for rule assembly and additional memory is required for the Rules Assembly cache.

Starting
Activity to
execute

Identify the first activity that the system executes after this user is authenticated. The standard activity for this purpose is named Data-Portal.ShowDesktop. This activity displays the user portal defined in the user's access group.

License Type

This field affects how the License Compliance facility classifies users who authenticate using this Operator ID instance. Depending on the terms of your license arrangement with Pegasystems Inc., the value you select for this field may affect license compliance tracking and usage reporting. See Working with the License Compliance facility.

In most cases, select:

• Named if this Operator ID is a person who interacts with PRPC through a Web browser.
• Invocation if this Operator ID is for processing performed through service calls, or for processing by external users (typically through the Directed Web access feature)

Default Locale

Optional. You can associate an initial locale with this operator that affects the processing and presentation of dates, times, and numbers.

For example, enter de_DE to use the German display mode for dates (DD/MM/YY) rather than the American mode ( MM/DD/YY).

If the locale setting for the user's Windows workstations should apply for the application, leave this field blank.

If the field is not blank and the system contains locale-specific RuleSets corresponding to RuleSets that this user can access, the user can work with an entire localized application in the Process Work and Monitor Activity workspaces.

Optional. Select a time zone to be used for presenting dates and times to this user in:

• Work object history
• List view reports on work items and assignments
• Summary view reports on work items and assignments

For example, select America/New_York for the US Eastern time zone; the display adjusts correctly for daylight savings time. Select Europe/London for London time.

As a best practice, if all or nearly all operators in an organization are in a single time zone and follow a common business day calendar, leave this field blank for those operators who share the organizational calendar and time zone. Complete the Calendar and Time Zone fields only for the operators who are exceptions.

These values are grouped by zone, not alphabetically, in the drop-down list, starting with the zone that is 12 hours away from Greenwich, England. Time zone codes follow the Olson TZ database, used in the ICU4J 3.4.4 library and most UNIX systems. Details on the Olson TZ database are available from http://twinsun.com/tz/tz-link.htm and ftp://elsie.nci.nih.gov/pub.

Do not type a three-letter code in this field, as such codes are ambiguous in certain cases and may produce incorrect presentation of daylight savings time in other cases. For details, see Pega Developer article 24159 Issue: Avoid three-letter time zone codes because they do not support Daylight Savings Time.

Settings in this field only affect the presentation of DateTime values. Within the database, all DateTime values are recorded in universal time, informally known as GMT. As a result, a work item resolved in one country on Tuesday may be presented as resolved on Monday when the history is reviewed in another country.

As a best practice, if your organization has all its staff and servers in a single time zone, leave the Calendar and Time Zone fields blank. If most staff and all servers are in a common time zone, leave the Calendar field blank but complete a Time Zone value for the exceptional operators. If the organization has operators and servers across many time zones, create a Calendar for each time zone and specify both the Calendar and Time Zone fields in every Operator ID instance.

In PRPC Version 4, three-letter Java time zone codes such as EST for Eastern Standard Time were accepted for this field. Some — but not all — of the three-letter Java codes are also Olson time zone codes.

Calendar

Optional. Identify the first key part (Calendar Name) of a calendar instance that identifies the working days and holidays of this operator. At runtime, the system uses the current date in format YYYYMMDD as the second key part to find a calendar data instance. At runtime, if no calendar with a second key part exactly matching today's date is found, the calendar that matches the first key part exactly and has as a second key part the latest date not greater than today's date is used.

Select a valid calendar carefully. To simplify and reduce maintenance over multiple years, PRPC does not validate the value in this field when you save an Operator ID form.

As a best practice, if all or nearly all operators in an organization are in a single time zone and follow a common business day calendar, leave this field blank for those operators who share the organizational calendar and time zone. Complete the Calendar and Time Zone fields only for the operators who are exceptions.

Few standard rules depend on the value in this field; it is provided for application use. The calendar does not affect the ability of the operator to sign on, enter work, or perform assignments.

Your application can use this field to access a calendar data instance for the operator when calling date functions. For example, if the value of this field is HONGKONG and the current date is March 31, 2006, the system first searches for a calendar with key HONGKONG.20060331. If no calendar data instance exactly matches this key, the immediately preceding calendar instance if any that matches HONGKONG (such as HONGKONG.20060101) is used.

During log-in, if this field is not blank, both the calendar and the time zone are set on the requestor page as the calendar and default time zone (property pyRequestorTimeZone). If blank, the system uses the calendar from the Organization data instance and does not set a time zone; the time zone is then typically defaulted to the time zone of the server node.