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:

  1. The Title can be any text that describes your Allowed Value Type.  The title is not used in any processing and is purely a label
  2. For the Parent field, select the field that is the parent in the relationship. This fields is required
  3. Select the Child field that is dependent on the parent value you selected. This fields is required
  4. You may enable and disable the allowed value using the checkbox with the title of Enabled
  5. 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.
  6. Reverse allowed values are a special case for allowed values.  These allow the end user to not only choose a valid child after selecting a parent value but also allow the end user to choose a child value and to then see the valid parents.  You will typically only use this in a scenario where each parent has unique children and the children are not shared across more than one parent.  You must set the behavior setting named AV_NULL_PARENT_IS_NULL to a value of NO when using reverse allowed values
  7. 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. Most allowed values should use the Ajax Refresh.  When you choose a new parent value, the child list is refreshed via a call to the server from the user’s browser.  The Ajax refresh type also ensures that any business rule or user custom programming call is made when the parent value changes.  This is fast and efficient
  8. Click the Add button.

Note: On occasions, you might want to create an allowed value list where only a subset of the values in the list will appear. For example, you might have retired some of the values in the child list and only want current values to appear. You can achieve this by using the AREA field as the parent, and the list field as the child.

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 is deprecated with ExtraView version 9.1, and new allowed value types can no longer be created that use this method, but its use is retained for existing allowed value relationships that had this set in previous versions.  You should update the allowed value type to use Ajax Refresh.  The JavaScript refresh 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.  Ajax Refresh allowed values have proved very efficient and have none of the drawbacks of JavaScript refresh, hence the reason for their deprecation.

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. The data dictionary display type for all the fields must be List, Popup or Tab. Other display types will not work.

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.

Reverse Allowed Values

It is strongly recommended that you only use this feature when there is a single parent to all the children within a list and the lists are not excessively large.  You may use the feature with cascading allowed values, but all the individual allowed value relationships must set the Enable reverse allowed values checkbox.  When reverse allowed values are enabled, ExtraView initially fills all the fields in the allowed value relationship with all the parent values and all the child values.  When a user selects any value in any of the fields in the allowed value relationship, the remaining fields are all filtered, both parents of the selected value and children of the selected value. 

For example, if you have an allowed value relationship with a parent and child field, the user may then select a child value and the appropriate parent is then selected.  If there is a cascade of three fields, and the user chooses a value in the middle field list, then the value in the parent field is selected.  The child values in the third field list are then filtered to only display the valid children for the second field.

When a user selects a parent, then all child fields are filtered as with regular allowed value lists.

If the user selects * None * in any list within the allowed value relationship and reverse allowed values are enabled, then all fields in the allowed value list are reset to their initial values.

For reverse allowed values to work, all the fields in the entire chain of allowed values must be on the layout, and must all have read and write permission.  This includes using reverse allowed values on a report or Quicklist layout.

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
  • When allowed values are populated as children on an add or edit screen by an end user, all the possible allowed value parents automatically become parents to the new child value.