Creating Allowed Values

The administrator creates allowed value definition (the allowed value type) from the Fields & Layouts tab on the administration menu, click Allowed Value Types and Combinations. The administrator also creates the allowed value combinations from within the same utility. The administrator can configure list type fields such that end users may add new values to a list (the ADD_NEW layout cell attribute). See the section at the end of this page regarding the configuration of allowed values when an end user adds a value to a list field.

The following screen appears when the administrator uses the Allowed Value Types and Combinations utility:


Allowed Value Types screen

To create a parent-child dependency between Category and Priority (using a sample Title of “Test”), you would do so as explained below:

  1. The Title can be any text that describes your Allowed Value Type.
  2. For the Parent field, select the field that is the parent in the relationship. Then select the Child field that is dependent on the parent value you selected. These fields are both required
  3. If you check the box against Warn end users about stale values then end users are warned when they edit a saved issue and a parent or child value in an allowed value relationship has been deactivated since the record was saved. The end user is informed that they can continue, but if they alter the saved value, they must choose a current valid value or leave the stale value. If this box is not checked, then the user is not issued the warning but the same rule applies. If the end user chooses a new value, it must be valid.
  4. The most common allowed values use the Ajax refresh type. This means that when a user selects a parent value on an Add or Edit screen, the server is accessed with an Ajax call which determines what the values should be in the child list. The Ajax refresh type also ensures that any business rule or user custom programming call is made when the parent value changes
  5. If you are creating an allowed value where the Parent field is either AREA or PROJECT, you should select Page Refresh as the refresh type. This is because a page refresh always occurs when a user changes the AREA or PROJECT field on an Add or Edit screen. If you select a different type of refresh when the parent is AREA or PROJECT, you are adding unnecessary overhead to the processing, which might degrade the performance of your system.
  6. If you select JavaScript Refresh, the client browser uses JavaScript to update allowed value lists. This should be used for lists that contain a relatively small number of combinations of parent and child values. Do not use JavaScript refresh if you are executing business rules based on a change in the parent or child value, as these will not be recognized and executed. The size of the list that may be displayed using JavaScript refresh is controlled by the behavior setting named REFRESH_LIST_MAX_SIZE. This setting is the number of combinations of parent and child values that will be downloaded to the client browser for processing, before ExtraView will use a Page refresh.
  7. Click the Add button.

Note: If a field is a parent in more than one Allowed Value Relationship, you should not use JavaScript Refresh.

Note: You can create an allowed value relationship without specifying a Parent field name. This is useful under the following circumstance. You may want to create a list based upon itself. This may sound odd, but you can then only allow some of the values to appear on the screen. This has the effect of disabling specific values in the list, perhaps because you have retired their use.


New Allowed Value Type

More about Refresh Methods for Allowed Values

There are three methods that can be used:

  1. Ajax Refresh. When the parent value is selected, an Ajax call is made to the server to retrieve only the child values. The child list is refreshed, but the remainder of the screen is untouched. This provides a fast means of dealing with large lists, without the need to repaint the entire screen. For most purposes, this method should be used for maximum efficiency.
  2. Page Refresh. On all changes of the parent value in the allowed value combination, the program returns to the server for the new data in the child list. This is primarily used when the parent field is either AREA or PROJECT. These fields, by definition, require a page refresh, therefore setting this refresh method minimizes the amount of work needed on the server, and delivers the smallest amount of code to the browser.
  3. JavaScript Refresh. This method pre-calculates all the possible combinations of parent and child values and delivers these to the browser. For relatively small lists, this is very efficient. However, if either the parent or child value has a business rule that needs to be triggered when its value changes, then this type of refresh does not have the built-in intelligence to call back to the server to execute any business rule. The recommendation is to use JavaScript Refresh for modest sized lists where there are no business rules to be executed.

The same field may be used as a parent to more than one child field by creating more than one allowed value type. Each of these allowed value types may have any one of three refresh types. When a parent field is changed by a user on an add or edit screen, only one of the above three methods can be used. Which method chosen is decided as follows:

  1. If there are any JavaScript refresh types for the parent, then a JavaScript refresh is done for all child values
  2. If there are any Page refresh types for the parent, then a Page refresh is done for all child values
  3. If neither of the above was true, an Ajax refresh is performed.

Cascading Allowed Values

It is possible to construct allowed value relationships that “cascade”, i.e. you define a parent – child relationship for one pair of fields, and then define a second parent – child relationship where the parent is the child of the first relationship. This forms a grandparent – parent – child relationship between three fields. There are some restrictions about this usage:

  • The data dictionary display type for all the fields must be List, Popup or Tab. Other display types will not work
  • You must set JavaScript refresh to No for each of the allowed value relationships, if the display type is Popup or Tab.

The child field select list will always show only * None * as a possible value, until both the grandparent value and the parent values have been selected.

If you alter the metadata associating the allowed values, in such a way that editing a record causes a child record to be invalid, a warning will be displayed by ExtraView, informing the user that the child value is no longer valid. The invalid value is still displayed at this time though. If the user alters the values of the grandparent or parent, the invalid value in the child field will no longer be displayed.

Allowed Value Parent Fields with Multiple Child Fields

One parent field may be the parent to multiple child fields. When you set up layouts with this scenario, you may also use JavaScript refresh to maintain the lists for users, provided that there are no more than 10 child fields for the parent. In the very rare and exceptional circumstance that you need more than 10 child fields to a single parent, then server-side refreshes will still work, and with no restriction on the number of child fields to a single parent.

Allowed Value Child Fields with Two or Three Parent Fields

You may create two or three allowed value relationships for the one child field, with different fields as the parent field. When you create this scenario you individually populate the allowed children for each of the parents in their respective allowed value lists. When you include the two or three parent fields and the one child field on the same add or edit screen, then the children that are visible will be those that have common parents. If a child value only has one of the parent fields as an allowed value, the child will not be displayed and it is not a valid selection.

If only one parent and the child exists on the add or edit screen, then this combination will work correctly as the simpler single-parent allowed value combination.

The parent and child fields used for this combination must all be enumerated lists with a display type of List, Popup, Tab, Checkbox, or Radio button. User display types are not supported at this time. Note that you should not use JavaScript refresh for an allowed value with multiple parents.

Allowed Value Additions by End Users

The ADD_NEW layout cell attribute controls the ability of an end user being able to add a new value to a list on the add or edit screens. If a field with this layout cell attribute is the child in an allowed value relationship, there is control over the behavior of adding the new field value as a child of the allowed value relationship.

The control is achieved through a behavior setting named AUTO_POPULATE_ALLOWED_VALUES. When this setting is YES, then in a popup from an add or edit screen that adds a new value to a list, and that list is the child within an allowed value relationship, then the new value will be added to the list and will be automatically added to the currently selected parent(s). If the value is NO, then the user will be prompted to select the Business Area, Project and the specific parent values to which the newly created child value will be added within the allowed value relationship.

  • If you are adding a child list value from the add or edit screens, you must have the parent field value accessible on the layout add or edit layout
  • If the child field belongs to more than one parent, the value of AUTO_POPULATE_ALLOWED_VALUES is overriden and always behaves as if it is set to NO
  • If the parent field is multi-valued, and multiple values are selected, ExtraView starts with all the selected parent values checked and the user can de-select or select additional values as they wish
  • When selecting the business area and project field values, the process starts with the currently selected business area and project. There is a check to see if there are allowed values defined at that level. If not, the process moves up the layout inheritance tree until an allowed value is found. If none are defined, but the allowed value type exists, the allowed value is created in the global area and master project.