|
|
Optional. Complete the Display Options tab to control the presentation of form-level and field-level error messages. You can customize the fonts, colors and image used in field-level messages in the Skin rule. See Skin form — Styles tab — General — Errors.
Also use this tab to configure optional logging of each use at runtime of this rule.
Field |
Description |
Display Form-Level errors | |
Form-level errors are reported against properties not present on the current form. By default, the messages appear in a standard form-error message section. You can display the error messages in one of three ways:
|
|
Always show form level errors | Check this box so that a form-level error message appears in the standard form-error section when a field-level error occurs. |
Custom Error Section |
For an example, see PDN article 26403 How to create a custom error section in user forms.
|
Display Field-Level Errors | |
Field-level errors (such as leaving a required field blank) are reported against properties on the current form. You can display them in one of two ways:
|
|
Keep fixed header/footer visible |
Leave cleared in most cases. Check this box to cause the entire runtime work item to scroll vertically as a single unit, except for the button bar and form error area which remain visible at the top. |
Container Icons | |
Show Container Icons |
Clear this checkbox so that the header icons are not displayed to the user. |
Screen Size | |
Has Minimum Width? |
Select to have the system at runtime conform to SmartLayout styles in the skin that determines the smallest width a user can compress the screen width before text is truncated and when horizontal and vertical slide bars appear. The minimum value provides consistent alignment by preventing columns and text from wrapping. |
Complete these optional fields to record each time a user requests the user form based on this harness. Each time the form appears, your application can add an instance of the Log-DataAccessAudit class, to support later compliance auditing, reporting, and analysis. The added instance identifies the date, time, Operator ID, harness, Customer party (if any) and work item ID.
Logging occurs upon initial display of the form; it does not require that the user update any fields. You can create list view rules and summary rules to report on Log-DataAccessAudit instances, or export the data for analysis.
(On the Security tab of the Flow Action form, you can provide a similar logging capability for flow actions.)
Enable this feature only if such detailed auditing is needed in your application. Auditing increases the database workload of your application and can produce large volumes of log data.
Field |
Description |
Auditing | |
Audit Use? |
Select to enable auditing of the user forms produced by this harness. The When and Audit Activity fields become visible. |
When |
If blank, the activity is always executed. |
Audit Activity |
You can use the standard activity Work-.Audit here, or a similar activity that meets the needs of your application and adds an instance to the Log-DataAccessAudit class. The Work-.Audit activity records the full name and identifier of a work party with the party role |
Params |
If the activity uses input parameters, click to provide values for each parameter. The system automatically completes the following four parameter values; you do not need to complete them.
|
This section will appear only if the Pega-Mobile RuleSet is part of your application.
Field |
Description |
Mobile | |
Supplemental Toolbar Navigation Rule |
Be careful to reference a navigation rule of type |