Summary

Introduced in V6.2 SP2, the private check-out feature allows developers to prototype or test changes to an existing rule that is not available for standard rule check out. This feature lets you rapidly debug a rule that is in a locked RuleSet version, while avoiding impacts on the rest of the application or its users.

Suggested Approach

Private check out is a special case of the standard check-out feature. In standard check out, a developer checks out a rule, and no one else can check out that already-checked-out rule until the developer checks it in. Because no one else can modify the rule until it is checked in, the check-out feature prevents developers from overwriting each other's work.

When a developer checks out a rule, a copy of the rule is created in that developer's personal RuleSet, and the system protects the base (copied) rule from modifications by others. The developer modifies his copy of the rule, and then when he checks it in, the system replaces the base rule with the modified copy and removes protection of the base rule.

The private check-out feature provides a way for developers to use their personal RuleSet as a "sandbox" in which to work with rules that the system has otherwise protected from changes. Examples of the benefits and types of situations in which private check out is typically used are:

• Simplifies the process for debugging a rule when the application rule and its RuleSets are locked — An application in a production system usually has its RuleSets and application rule locked, so that no one can introduce accidental changes to the in-production application. Without private check out, to debug a rule in a locked RuleSet would require making a copy of the rule by saving it into another RuleSet. However, when the application rule is locked, adding an additional RuleSet requires unlocking the application rule, updating it, and saving it. Sometimes that is not feasible. With private check out, a developer can test changes to the rule to determine the cause of a bug without needing to introduce any additional RuleSets or "test" applications on the production system.
• Enables multiple developers, working separately but in parallel, to try out changes to the same rule — With standard check out, other developers are prevented from changing a rule while one developer has it checked out. By using private check out, multiple developers can immediately explore the effects of different changes to the rule in parallel.

How to enable a developer to use the private check-out feature

For a developer to be able to use private check out for a rule, he or she must first be able to use check out for that rule. The ability to use check out on a rule is provided when the following conditions are met:

• The RuleSet that contains the rule has the Use check-out? checkbox selected on its rule form's Security tab.
• The developer's Operator ID form has the Allow Rule Checkout checkbox selected on its Advanced tab.

For private check out, in addition to those two conditions, a developer needs the pxAllowPrivateCheckout privilege. This privilege is usually granted through a role on your access group. For example, the standard application: Administrators access group created by the Organization Setup wizard uses a role that provides this privilege.

How to make a private copy of a rule using private check out

For a rule that is contained in a RuleSet enabled for check out, the system determines whether it is available for standard check out, or whether it is protected and is available for private check out only. If the rule is available for private check out, click in the rule form's toolbar.

The system creates a private copy of the rule in your personal RuleSet. The rule form header indicates the private copy is from a private check out.

Next steps after changing a privately checked-out copy of a rule

The steps you take after making changes to your privately checked-out copy of a rule depends on your situation, and the conditions that led to your using the private check-out feature for the rule.

Example 1

For example, if you are debugging a rule when:

• the application is in production,
• its RuleSet versions are locked,
• your changes to the private copy fix a bug,

the typical next steps are:

• review the changes with the owning organization and get their agreement to include the updated rule in the application,
• schedule the work to unlock the application rule and appropriate RuleSet,
• create the applicable destination for the updated rule (for example, a new RuleSet or RuleSet version), add the new destination to the application rule (as applicable), and then check in your privately checked-out rule to that destination.

To check in a privately checked-out rule to the new RuleSet version, click in the toolbar in the rule form. Specify the destination RuleSet Version for the updated rule in the window that opens.

Example 2

If you complete your work on a privately checked-out copy of a rule and find that the rule has changed since your checkout, or another developer also has the rule checked out, you must determine whether your changes to your copy of the rule should be applied to the base rule.

Work with any developers who have changed the base rule since the time you made your private copy and see how (or whether) is the best way to apply your private changes to the base rule.

If you determine that your changes should be applied, you can check in your privately checked-out rule by clicking in the rule form.

If you determine that your changes to your privately checked-out copy are not applicable and do not need to be saved, you can delete your private copy by clicking .

Additional information

 Using branch RuleSets and merging for parallel development