Click for end user documentation
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:
Module Owner Module Release (example of a cascading allowed value) Product nameYou 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 has up to fiveparent fields 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.
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. |
