Access Group form
Completing the Advanced tab

Field

Description

Lists the classes that are marked as Is a Class Group (on the rule form's General tab) for each work pool in which users associated with this access group are permitted to create cases. Each such class defines a work pool, a named collection of case types.

You can enter any class group for which the container class (the Rule-Obj-Class instance with the same name as the class group) belongs to a RuleSet listed in the Production RuleSets array or available to users through application rules. This restriction ensures that the rules of the application (in addition to the case types) are available to users associated with this access group.

As a best practice, select the radio button on the class group that contains the case types in which users associated with this access group most often create cases. This selection determines the default work pool that appears on the top of the Application Explorer tree when you open an application.

The names (the class rule Short Description text) of the workpools listed here appear in the Application menu Switch Workpool list.

If you leave this array blank:

• When you open an application, the Application Explorer class auto-complete field is empty; no classes appear in the tree.
• Operators associated with this access group cannot create cases. However, the array does not affect which cases the operator can update, only which types of cases the operator can create. The assignments the operator can open and update is determined by access roles and RuleSet lists, not by the work pools.

Work pool names appear on this Work Pool Selector list in the order that the corresponding work pools are listed here. If this array contains more than a few, consider reordering them to present the work pool names alphabetically, or in another order meaningful to users.

Leave blank if users who enter new cases and are associated with this access group use a composite portal that includes the standard section @baseclass.NewWork. The cases that such users can enter appear on the Cases and Data tab of the Application rule, not here. See How to create a composite portal.

For users of the traditional WorkUser or WorkManager portal rules, this list determines the set of work pool names that appear in the Work Pool Selector (typically visible below the logo in the navigation panel) and the work types that appear in the selection list of the New.. box. The names appear in the order that the work pools are listed.

For example, if you designate the PegaSample class group as default, the corresponding work pool name is Sample Work.

When a user (at a traditional portal) associated with this access group enters new work items, the available work types are those from classes (work types) in the designated class group (work pool).

Field

Description

Enter a number of seconds after which the system challenges idle browser sessions (for users of this access group), asking users to re-enter their Operator ID and password. This timeout event does not cause session context or clipboard contents to be lost.

If users respond to the challenge and are re-authenticated, they can usually continue processing where they left off, unless the system released locks they held in the meantime, or the system was stopped and restarted.

This authentication timeout is not related to the timeout/browser value in the prconfig.xml file or Dynamic System Settings, which controls when passivation occurs. See timeouts.

Typically, accept the default of /webwb. Directories within this directory hold important static XML forms, JavaScripts, style sheets, and images.

If you have changed the name of this directory, enter the new directory name here.

This setting determines whether and how the system executes rules accessed by members of this access group.

In PRPC, rules can be made to require privileges in two ways:

• By an administrator explicitly editing the rule's Security tab (where such a tab is available).
• By a PRPC activity, pyRuleExecutionMessagesLogged, that automatically generates privileges and adds them to roles that access rules that require privileges.

Allow is the default, recommended setting. Deny is the strictest setting and requires creating privileges for rules and access roles.

Warn mode should be used only when you want to identify rules for which users need generated privileges to execute. You can then use the PRPC activity to generate missing privileges and add them to roles where needed. See PDN article Setting role privileges automatically for access group Deny mode.

Select one of these options:

• Allow [default] - The system allows users in this access group to execute a rule which has no privilege defined, or to execute a privileged rule for which the user has the appropriate privilege. (This includes privileges predefined for standard roles, set by an administrator, or generated by PRPC.) This is the default and recommended setting.
• Deny - The system checks for either of these conditions:
  • A privilege has been specified for the rule: The system checks whether the user has either an explicit privilege, or a generated privilege for the rule. If the user has either privilege, the system executes the rule. If the user has neither privilege, the system denies execution of the rule and logs an error message in the PegaRULES log.
  • No privilege has been specified for the rule: The system checks whether the user has the generated privilege. If the user lacks the generated privilege, the system denies execution and writes an error message to the PegaRULES log.
• Warn- The system performs the same checking as in Deny mode, but performs logging only when no privilege has been specified for the rule or the user role:
  • If a privilege has been specified for the rule, the system checks whether the user has either an explicit privilege or a generated privilege for the rule. If the user has neither privilege, the system denies execution of the rule.
  • No privilege has been specified for the rule: The system checks whether the user has the generated privilege. If the user lacks the generated privilege, the system allows execution and writes a warning message to the PegaRULES log.
    
    Warning messages are used to generate privileges with pyRuleExecutionMessagesLogged.

Best practice - Use Allow mode for Rule Security Mode, and use the Access Manager to configure authorization for rules. When more specific security is needed for an individual rule, specify a privilege for the rule. See Access of Role to Object form - Completing the Privileges tab. If you want to specify privileges for all rules and users, and you have sufficient time and resources to perform a system-wide exercise including all expected users, see the PDN article Setting role privileges automatically for access group Deny mode.

Field

Description

Optional. Enter production RuleSets and Versions specific to this access group. For example, in a production setting, you can identify one RuleSet and Version that remains unlocked and holds only rules expected to be changed often. Such rules may be delegated to management. A RuleSet with this purpose is sometimes called a local-only or production RuleSet.

Leave blank except for developers and others who modify rules. While your profile includes the RuleSets versions listed here, they are not considered part of the current application. Rules in the RuleSet versions listed here may not be visible in the Application Explorer, Guardrails tool, or Document wizard facilities.

As a best practice for good security — and to avoid a warning when you save the Access Group form, select from the RuleSet versions that appear in the Production RuleSets array on the Definition tab of the application rule.

The system uses this information at log-on time to assemble the RuleSet list for this user. The order of your entries in this array affects rule resolution. At login, the system appends these entries to the top of your RuleSet list, but starting at the bottom of this array. The order of rows in this array becomes the order they appear in the RuleSet list.

For example, if during sign-on this access group is accessed when the (partial) RuleSet list contains Alpha:01, Beta:02, and Gamma:03 (in that order), and this array contains Red:07, Blue:08, and Green:09 (in that order), the result is Red:07, Blue:08, Green:09, Alpha:01, Beta:02, Gamma:03.

You can include a full version number or an initial portion of a version number. Separate the RuleSet name from the version (or partial version) with a colon, as in:

• MORTGAGE:02-07 — Initial portion (major and minor version)
• MORTGAGE:02-07-20 — Full version number

Except for users who have the PegaRULES:WorkUser4 role, include at least one RuleSet version that is not locked. If all RuleSet Versions that a user can access are locked, that user cannot create new rules. (Typically, managers have access to a local customization RuleSet for storing only those rules that are personal customized versions of list view or summary view reports.)

List distinct RuleSets here. A user or other requestor can access rules in only one major version of a RuleSet; access to version 04-10-15 includes access to 04-10-14 and 04-04-11, but not to 03-01-01 or 02-15-07.

To reorder the rows of this array, hold the mouse pointer over a number. Click and drag to another row. To duplicate or move a row, hold the mouse pointer over a number. Or, right-click to access a menu with Cut, Copy, and Insert options.