Business environments change, sometimes suddenly, in response to external change or internal decisions. PRPC allows you to design and implement applications that respond to change with agility and efficiency.
By recording business practices and policies in records rather than in code, all PRPC applications provide a degree of modularity and transparency that can simplify maintenance. For example, line managers can review and comment on a business process presented as a Process Modeler diagram, even without knowing Process Modeler how to maintain a flow record.
To go beyond this basic PRPC benefit, application developers can delegate responsibility for updating selected important parts of each application to business managers. This promotes:
Users who have the PegaRULES:WorkMgr4 access role (or other roles that include the UpdateLimitedForm privilege) can view and update the leftmost tab of any delegated record. They can also view and update the History tab.
By design, the leftmost tab of the forms for ten rule types provides access to fields most likely to change over time. Although records of any type can be delegated, managers are most likely to learn and understand the following types:
To empower managers to change selected records:
delegated rule | |
How to delegate a rule
PRPC documentation |
The spellchecker software operates on the PRPC server, using the dictionaries, features, and settings identified in a Data-SpellChecker-Properties instance. See About SpellChecker Properties data instances.
Spellchecking is available only for user forms based on harnesses that use the SmartFrames form of the Layout tab and include the spellchecker icon.
To include the spellcheck capability in a user form:
Spell Checker
as the Type. The corresponding icon appears on the form (). See Harnesses, Sections, and Flow Actions — Adding an Icon.This step is optional. By adjusting the HTML representation of a property, you can control which properties can be spellchecked. (Users can check spelling can only for properties presented in read-write mode, which allows the corrected spellings to be entered.)
By default, spellchecking is enabled for input fields that reference Text Area (pxTextArea) and disabled for Text Input (pxTextInput) auto-generated control rules. This functionality cannot be modified.
Non-auto-generated controls
By default, spellchecking is enabled in the non-auto-generated control rule TextArea that produces an HTML tag of the form:
<INPUT TYPE="TEXTAREA" ... >
To disable spellchecking for a property that is represented with a TEXTAREA tag:
SPELLCHECKENABLED="false"
to each <TEXTAREA> tag. By default, spellchecking is disabled in the non-auto-generated control rule Text that produce an HTML tag of the form:
<INPUT TYPE="TEXT" ... >
To enable spellchecking for a property that is represented with a TEXT tag:
SPELLCHECKENABLED="true"
to each <INPUT TYPE="TEXT" > tag.When the spellcheck icon is visible at runtime, any user who can update the work item can perform the spellcheck. The current locale of the user determines which SpellChecker Properties instance applies, and so which dictionaries apply. Users can change their locale through Windows workstation facilities, the Locale Settings tool, or by running an appropriate activity.
Only users who hold the privilege @baseclass.AddtoDictionary can insert new words into a user dictionary. Such users must also have the ability to update rules in the RuleSet version that contains the user dictionary (a text file rule).
About control rules
About SpellChecker Properties data instances About the Locale Settings tool |
|
Atlas — Initial SpellChecker Properties data instances |