上QQ阅读APP看书，第一时间看更新

Reverse if False

The Reverse if False tick-box (which is only available on the Advanced view of the UI Policy and Catalog UI Policy forms), allows us to specify whether the UI Policy Actions (or Catalog UI Policy Actions) associated with our UI/Catalog UI Policy have their actions reversed whenever the Condition associated with their parent policy does not evaluate to true.

For example, imagine we have a condition [Assigned to][is][empty] on a UI Policy. When met, a UI Policy Action is triggered, which sets the Assignment group field to Mandatory. This way, if we don't have an assigned user, at least we can be sure we have an assigned group.

In this scenario, if we have Reverse if False enabled, then as soon as the assignment group field contains a value, then not only is the UI Policy Action which made Assignment group read-only no longer applicable, but another action with the opposite effect is fired, actively setting the Assignment group field to non-mandatory. This applies even if the field is made mandatory by another means; and this is where Order comes into play. More on order and how to create robust policies that do not conflict, later in this chapter.

As you can imagine, Reverse if False can be an extremely powerful and useful tool, but it can also be the source of a great deal of confusion, if it behavior is not well understood in the context of all of the UI Policies and Client Scripts that might run on a given record or form. It is not necessary, and not recommended, to set a field to Read-Only = False if that field is not normally read-only. Only if you need to alter some behavior, should the field's properties be set by a UI Policy; otherwise, the Leave Alone option should be selected. Leave Alone does not result in any action, which means that there's nothing to reverse in the event that the condition on the policy is not met.

There are a few circumstances where Reverse if False should not be used, but the vast majority of UI and Catalog UI Policies leave this option enabled. It is usually only used when you have one UI Policy controlling the behavior of a given field or set of fields under one condition, and a separate UI Policy controlling their behavior under the exact opposite condition. In a situation like this, it's important to be careful not to modify one of the policies without modifying the other to match, or you could end up with aberrant behavior.

If the condition on a UI policy returns false, then one of two things might happen:

If the Reverse if false tick-box is selected, then the opposite of the UI Policy Actions are enforced. For example, if a UI Policy Action sets the Short Description field to visible when the conditions are matched, then having Reverse if False enabled would make it so that the short description field is hidden when the condition is not matched.
If Reverse if false is not selected, then the UI Policy simply does nothing.
This does not mean that the UI Policy Actions are undone. Say for example, that you have a UI Policy which causes the Work Notes field to become mandatory when the State field is set to Closed, but the Reverse if false tick-box is unchecked. In this case, if the user set the State field to Closed, then Work Notes will become mandatory. However, if the user then changes their mind and sets the State field to another state such as Work in progress, then the Work Notes field will remain mandatory.