Procedure – Pre-Validation

Depending on whether you’re validating actions or attributes, the validation statuses you’ll return from your filters or validators will vary. This section describes some of the rules and best practices for determining which validation statuses to return in certain scenarios.

The validation service and client infrastructure currently support three statuses for pre-validated actions: “enabled”, “disabled”, and “hidden”. As you might suspect, an “enabled” status means that the action is visible to the user and selectable for the user. The “disabled” status means that the action is visible to the user, but not selectable (i.e., the action is “grayed-out”). And the “hidden” status means that the action is not visible at all to the user. Note that there is currently no support to “disable” actions rendered as icons (in a table header or table row, for example). If the validation service returns a “disabled” status for an action icon, the client infrastructure will simply hide the action icon.

Whether you’re implementing a filter or validator to perform pre-validation logic, you’ll be expected to return a validation status (either directly or wrapped in a validation result) to the validation service. (If you implement a solution group, the validation service automatically assigns a “hidden” status to all components deemed invalid by that solution group.)

When trying to choose which status to return from your validator or filter, use the following rules of thumb:

• Always err on the side of enabling. If you can’t determine conclusively whether or not an action should be available, give it an enabled status. Chances are there is additional validation that will occur down the line (whether it be another filter, a validator, or post-select validation) when there is more context information available that can disable or deny the user. You’re almost always better off showing a user an action they can’t perform than hiding an action that they should be able to perform.

• When trying to choose between hidden and disabled, ask yourself whether the action could ever be visible to the user in the current context. If the answer is yes, then the status should be disabled. For example, the “check-out” action is not valid for an object that is currently checked out. But if that same object wasn’t checked out, the “check-out” action would be available to the user. In that case, a disabled status is appropriate. However, suppose you had an action that was only available to admin users, and your user is a non-admin. In that case, the action would never be available to that user, so a hidden status would be appropriate.

The validation service and client infrastructure currently support four statuses for pre-validated attributes: “hidden” (ATTR_HIDDEN), “hidden value” (ATTR_HIDDEN_VALUE), “read only” (ATTR_READ_ONLY), and “visible” (ATTR_VISIBLE).

The “hidden” status means that the attribute’s name nor value is never displayed in the UI. The “hidden value” status means that the attribute’s name will be displayed, but not its value. The “read only” status is used to indicate that an attribute’s name and value are displayed, but that user may not modify the value. And the “visible” status is used to indicate that the attribute’s name and value will be displayed and that the user may modify the value when it is available in a form or wizard.

To determine which status applies to your attribute under certain conditions, you should probably seek clarification from the customer, product manager, etc. There aren’t really any generic rules that can be applied to all attributes.

You may recall that a single filter can be applied to multiple actions and attributes. So you may be wondering which status the filter should return in situations where it may be applied to both actions and attributes. In those situations, use the statuses reserved for actions (“enabled”, “disabled”, and “hidden”). The client infrastructure will treat “enabled” like “visible”, “disabled” like “read only”, and “hidden” like “hidden”.

When applying a validator to an attribute in a table the validator will be applied to the entire column. The validators for an attribute cannot be applied to a single cell. The entire column will receive the most restrictive state found for any column. For example, if one cell is read only and one is hidden, the entire column will be hidden.

The second pre-validation check performed by the validation service is to call the role-based UI service to see whether or not an admin user has configured a component to be hidden or disabled for certain users. This check is built into the validation service, so there is no work for a customizer to perform. For more information about configuring the role-based UI service as an admin user, please see Customizing Role-Based UI Functions — Action Visibility.