Allowed Values

Allowed Value Lists give you the opportunity to have certain field lists and their values be dependent on other values in other list fields; for example, a list of specific Platforms may only be displayed if the connected parent Product is first selected. The following Parent Child relationships would be set up so that OS 9 or 10 platforms would only appear for Mac products, and Red Hat only appear for Linux.

Product Platform
Macintosh Client OS 9.x
Macintosh Client OS 10.x
Linux Client Red Hat
Windows Client Windows 98
Windows Client Windows XP

In the above example, when you select the product named Macintosh Client, the ExtraView Add Issue or Edit Issue screen will refresh, and the field titled Platform will have the two values OS 9.x and OS 10.x. This feature can be used both to ensure data entered is valid, and that data entry can be accomplished with a minimum of searching. Allowed Values can be “chained” together, providing a cascading set of values. Common examples of allowed values are:

  1. Product name Module
  2. Module Owner
  3. Category Module Release (example of a cascading allowed value)
  4. Category Product name

You may create chains of any length of allowed values; in concept, think of a grandfather father child grandchild type relationship. With some limitations it is also possible to build multiple allowed value relationships where the same child field may have two or three other fields, each of which is a parent in the allowed value relationship you are building. In this case, the child field is rendered using the intersection of the allowed values from each of the parents.

Not every combination of fields is allowable to be created as allowed values. For example, it is not possible to create an allowed value with a combination of MODULE_ID or MODULE_NAME and PRODUCT_NAME, as another inbuilt mechanism exists to handle this requirement.

Allowed Value Usages

These are typical usages for different configurations of allowed values, within different places in the ExtraView environment.

Both parent and child fields exist within an Add or Edit screen This is the most common usage of allowed values.  The child fields are simply filtered according to the parent value chosen.  Before a parent field is chosen, the child field has no values

A parent and multiple child fields exist within an Add or Edit screen

In this instance, each child field is filtered according to the parent field that is chosen.  Before a parent field is chosen, the child fields have no values
Both parent and child fields are configured to use the Reverse Allowed Value option It is recommended that a parent only is configured to have unique children, as opposed to a child field being the child of more than one parent. Both parent and child fields are populated initially with all values.  If the user selects a child value before selecting a parent, the parent list is filtered to only show the valid parent.  If the user selects a parent before a child, the child list is filtered to only show valid children of the chosen parent
 
The parent field resides on an Add or Edit screen and the child field exists within a Search layout embedded within the  Add or Edit screen This allows a search field to be populated with a value dependent upon the selected parent field.  The user may still choose a different value from the child list
The parent and child fields both reside within a Search layout embedded within the  Add or Edit screen Allowed values work in the expected way, where the child fields are simply filtered according to the parent value chosen.