Share this page

# Considerations for configuring advanced UI rules

Well-designed UI rules require some planning. This topic provides some guidelines to help you construct useful UI rules that do not have unwanted results.

In this topic:

## Considerations for configuring advances UI rules

Pay attention to the following when configuring advanced UI rules:

Consideration | Details
--- | ---
Consider all possible events and negative cases | Make sure you handle what happens when the page is loaded, when field values change, when the page is saved, and so on. If you set up a rule to be triggered 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.
Consider field security and dependencies | 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 enable only one user to view or edit a field by using the field level security, make sure you don't enable other users to view or edit the field by UI rules. If a field's Display attribute is set to No or the field is set to be invisible by its status dependency, you cannot make it visible on the Web UI by using UI rules.
Pay attention to the field validations | If you configure SQL rules to set values for auto-complete lists, make sure that you only set valid values. PPM uses `#@#` as a separator. Make sure that: Values used in SQL rules do not contain `&amp;` or `#@#`. SQL rules do not contain `#@#`. The Dependencies field supports these validations: Text field, Auto-complete list, Drop-down list, and Date field (short, medium, and long) The validations supported in the Results field. For details, see Validations supported in Results field.

### Validations supported in Results field

The Results field supports the following validations:

Rule Validation | setFieldRequired1 | setFieldEditable2 | setFieldVisible3 | setFieldStyle | selectAll | unselectAll
--- | --- | --- | --- | --- | --- | ---
Text field | Yes | Yes | Yes | Yes | Not supported | Not supported
Text area | Yes | Yes | Yes | Yes | Not supported | Not supported
Auto-complete list | Yes | Yes | Yes | Yes | Not supported | Not supported
Drop-down list | Yes | Yes | Yes | Yes | Not supported | Not supported
Check box | Yes | Yes | Yes | Not supported | Yes | Yes
Radio buttons | Yes | Yes | Yes | Not supported | Not supported | Not supported
Date field | Yes | Yes | Yes | Yes | Not supported | Not supported
Web address (URL) | Yes | Yes | Yes | Yes | Not supported | Not supported
Link | Yes | Not supported | Yes | Not supported | Not supported | Not supported
Password | Yes | Yes | Yes | Not supported | Not supported | Not supported
Attachment | Yes | Not supported | Yes | Not supported | Not supported | Not supported
Table component | Yes | Not supported | Not supported | Not supported | Not supported | Not supported
Staffing profile | Yes | Not supported | Yes | Not supported | Not supported | 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. |  |

## Considerations for configuring rules in table component

Note the following considerations when you configure SQL rules and/or UI rules for table component:

- Set Process subsequent rules? option to `Yes` or `No` for different validations.

- Dependencies field is not required for Apply on creation rule event, but required for Apply on field change rule event.

- Dependencies field supports the following validations:

  - Text field

  - Auto-complete list

  - Drop-down list

  - Date field (short, medium, and long)

- Results field supports the following validations:

  - Text field

  - Text area

  - Auto-complete list

  - Drop-down list

  - Radio buttons (yes/no)

  - Date field (short, medium, and long)

  - Web Address (URL)

  - Link

- UI rules support the following JavaScript functions:

  - `setFieldRequired ()`

  - `setFieldEditable ()`

  - `setFieldVisible ()`

  - `showMessage ()`

  - `setFieldStyle ()`

    Note: To modify CSS styles, locate and access the `RequestRulesUserCSS.css` file in the following directory: `/opt/ppm/[`instance name`]/server/[`instance name`]/deploy/itg.war/web/knta/crt/css/`.

  For more information about these JavaScript functions, see Predefined JavaScript Functions (Advanced Rules Only) or access the Request Rules JavaScript Function Help by clicking the icon next to the Logic field in Rules window of the Validations Workbench.

- You can set table component as a dependency to trigger request type rules.

- When using SQL rule(s) on text field with Apply on creation rule event, make sure not to use strings "`~^~^~`" and/or "`~&~&~`" in any text field as they are reserved.

- When SQL rule(s) with Apply on creation rule event are triggered to override default value of a table component column, the default value may still display for a very short period of time (say 0.5 second) due to server speed.

## Limitations

Pay attention to the following limitations when configuring advanced UI rules:

- Rules can be executed on the printable version of Request Details, but with the following limitations:

  - Only SQL rules and the `setFieldVisible()` UI rule are executed.

  - Only the Apply on page load rule event is supported.

  - The printable version should be opened from the request details page instead of by entering the URL address directly.

- If you use special commands, for example, `ksc_store`, in a workflow execution step to change a field value, it does not trigger 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.

- If a request contains a rule that uses `KNTA_MULTI.Find_User_full_names([SYS.USER_ID])` from `sys.dual,` you cannot save the request, or remove associated entities from the request. . Use `KNTA_MULTI.Find_UserNames([SYS.USER_ID])` from `sys.dual` instead.

https://admhelp.microfocus.com PPM 8942
Tips to improve your search results... OpenText™ Project and Portfolio Management Help Center PPM Help 26.2-26.3 All View Local Help Center View Online Help Center Version: