RuleSet Version
form
Completing the Security tab
|
|
Use the Security tab to lock this RuleSet version, preventing any later changes or additions to the rules associated with it. This action is reversible.
While a RuleSet version is locked, no additional rules can
be checked out or checked in. The Save (
) and Delete (
) toolbar buttons are
unavailable, and the Read-only indicator (
)
appears at the top of the form.
You can
lock a RuleSet version at a time when one or more rules
belonging to the version are checked out. To avoid this, select
View > Rules > All Checkouts and examine the
results before locking a RuleSet version.
Field |
Description |
| Locking | |
| Lock this Version? |
Select to lock this RuleSet version. If selected, no one can save new rule instances to this RuleSet version, or update or delete existing instances. Clear this box to allow developers to save rules associated with this RuleSet version. You may be prompted for a password upon saving.
|
| Password to Unlock this Version |
If you checked Lock this Version, enter a password that hereafter any user must supply before clearing the value of the Lock this Version check box. |
| Enter Password Values | |
| To Unlock this Version |
Optional. If the Password to Unlock this Version field above is not blank, and the Lock this Version check box is selected, enter the value of the password above in this field. |
| To Add/Update this Version |
Optional. When creating (with New or Save As) a new version for this RuleSet, or updating any field on this version, supply a password that matches the values on Define Passwords area of the Security tab of the RuleSet Name form for these functions. |
Field |
Description |
| Effective Date | |
| Effective Starting |
This value does not affect normal system operation; rules in this RuleSet version are available before and after the date. If you leave this field blank and save the Version form, the system enters in this field the date that this version rule was created. The Effective Starting value affects processing only for requestor sessions that execute the PublicAPI method setRuleSets() to establish a cutoff date for RuleSets. This function revises the requestor session RuleSet list to exclude RuleSets with an effective date later than a supplied date. To negate or turn off historical processing, call restoreRuleSetList() . Your activity can call setRuleSets() multiple times with successively earlier dates, but you can't advance the date. So, to turn on 2005 processing after previously turning on 2003 processing, return to the current date with restoreRuleSetList() first. Such historical processing allows only "as-was" rules to apply (when this field is completed accurately and the setRuleSets() capability is enabled). For example, tax processing performed in 2005 may apply the tax rules in force as of January 1, 2003, if properly configured.
See Contrasting time-qualified rules, date-time circumstances, and historical processing. |
| Approval Process | |
| Require approval process for rules in this version? |
Select to require a development approval workflow, identified in the RuleSet Name rule, for check in of rules for this version of this RuleSet. See Using the Rule Check-In Flow. |
Identify other RuleSet versions upon which this RuleSet version depends; they are known as prerequisites.
Plan
prerequisite relationships carefully to avoid circular
dependencies. As a good design practice, define a purpose and
mission for each RuleSet, and encourage development team
members to place each new rule in the most appropriate RuleSet
version, with care.
Process Commander enforces RuleSet version prerequisites
only during development (as a developer adds or saves rules)
and as rules are imported during Import Archive operations.
Prerequisites are not enforced at runtime; the
user's RuleSet list and the rule resolution algorithm
determines which rules are available for users to execute.
Field | Description |
| Prerequisite RuleSet Versions |  |
Optional. Enter one or more RuleSet versions on which this RuleSet version depends, that is, requires as a prerequisite. For example, if you're creating a RuleSet version for an application that is to use activities and other rules in HomeSales:04-01-01, enter HomeSales:04-01-01. Enter all three pairs of digits in the version; you cannot enter a partial version here. Typically, your application depends on the entire Process Commander product. To reflect this situation, enter three product prerequisites, or ensure that a RuleSet and version directly or indirectly referenced includes them. This prevents the application from being moved with the Import Archive tool into a version 4 or 5.2 system:
The system assembles a complete required RuleSet version list from:
Therefore, if your RuleSet depends on Alpha:02-01-01, and Alpha:02-01-01 depends on Beta:02-01-01, only list Alpha:02-01-01. There's no need to list Beta:02-01-01 because it is already listed in Alpha:02-01-01. When developing rules in this RuleSet version, developers can reference activities and other rules in any RuleSet version in the total RuleSet version list. The system also uses this information during the upload function of the Import Archive tool. |
Locking a RuleSet
version does not prevent later changes to class rules in
the RuleSet, as a class belongs to a RuleSet but not to a
version. To prohibit changes to class rules, complete the
Optional. Enter an effective date for the rules in
this RuleSet version to support historical processing.
Use the format YYYYMMDD or click the calendar icon
)