Important Considerations for Configuring Advanced UI Rules
Configuring well-designed UI rules requires some planning. Here are some guidelines to help you construct useful UI rules that do not have unwanted results:
-
Consider all possible events and outcomes. Make sure you handle what happens when the page is loaded, when field values change, when the page is saved, and so on.
-
Consider negative cases. If you set up a rule to be fired whenever a field contains a particular value, make sure you handle what happens when the field is changed to a different value. You may need additional rules for that.
-
If you set a field as required based on a specific value in another field, you must ensure that you set the field as not required for other possible field values.
-
If you configure SQL rules to set values for auto-complete list, make sure that only valid values are set. Auto-complete component's valid value list is not in client UI, so when using rule to set values for auto-complete component, the values are not validated and invalid values can be set. As a result, when users create a request, a value that is not in auto-complete list can be inserted and saved in an auto-complete field as triggered by the SQL rule.
-
PPM uses
#@#
as a separator. Make sure that:-
Values used in SQL rules do not contain
&
or#@#
-
SQL rules do not contain
#@#
You can use
#
and@
separately. -
-
Rules can be executed on the printable version of Request Details, but with the following limitations:
-
Only SQL rules and UI Rule
setFieldVisible()
will be executed. -
Only Apply on page load rule event is supported.
-
The printable version should be opened from request details page instead of by entering the URL address directly.
-
-
If you set a field's field level security as only visible to and editable by one user, you can not make it visible to or editable by other users by using UI rules.
-
If a field's
Display
attribute is set toNo
or the field is set invisible by its status dependency, you can not make it visible on the Web UI by using UI rules. -
Dependencies field supports the following validations:
-
Text field
-
Auto-complete list
-
Drop-down list
-
Date field (short, medium, and long)
-
-
Results field supports the validations listed in the following table:
Rule
Validation
setFieldRequired1
setFieldEditable2
setFieldVisible3
setFieldStyle
Text field
Yes
Yes
Yes
Yes
Text area
Yes
Yes
Yes
Yes
Auto-complete list
Yes
Yes
Yes
Yes
Drop-down list
Yes
Yes
Yes
Yes
Radio buttons
Yes
Yes
Yes
Not supported
Date field
Yes
Yes
Yes
Yes
Web address (URL)
Yes
Yes
Yes
Yes
Link
Yes
Not supported
Yes
Not supported
Password
Yes
Yes
Yes
Not supported
Attachment
Yes
Not supported
Yes
Not supported
Table component
Yes
Not supported
Not supported
Not supported
Staffing profile
Yes
Not supported
Yes
Not supported
1. setFieldRequired UI rule does not work for the above validations when the Display attribute in the field property is set to No or the Visible attribute in Status Dependencies is set to No.
2. setFieldEditable UI rule does not work for the above validations when
- Display Only attribute in the field property is set to Yes, or
- Display attribute in the field property is set to No, or
- Visible attribute in Status Dependencies is set to No, or
- Editable attribute in Status Dependencies is set to No.
3. setFieldVisible UI rule does not work for the above validations when the Display attribute in the field property is set to No or the Visible attribute in Status Dependencies is set to No.
Caution: If a request contains a rule that uses KNTA_MULTI.Find_User_full_names([SYS.USER_ID])
from sys.dual,
saving the request may fail or removing associated entities from the request may fail. Use KNTA_MULTI.Find_UserNames([SYS.USER_ID])
from sys.dual
instead.
Note: Using special commands, for example, ksc_store, in a workflow execution step to change field value will not trigger rules.
If a field's Display
attribute is set to No
or the field is set invisible by its status dependency, you can not make it visible on the web UI by using request level UI rules.
SQL for Hierarchical Display (tree validation) now supports resolving such static tokens as [SYS.USERNAME]
and [SYS.USER_ID]
. Other types of tokens, such as Request Details or Context related tokens, are not supported.