Field value choices for dependent field are inherited from a child table to the parent table even if defined for the child table only


Description

Field value choices for dependent field are inherited from a child table to the parent table, even if they are defined for the child table only.



Steps to Reproduce

1. In the example scenario:

2. Open a record for table A, with the state field having the value the new substate was added for.

3. The substate will show the value that is specific to table B, instead of hiding it as when the field is not depending on another field.

Workaround

After carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address this issue in any current or near future releases. We do not make this decision lightly, and we apologise for any inconvenience.

The workaround is to create an onLoad (and onChange) client script, using the g_form.removeOption() statement to remove the unwanted choices for the parent table (table A in the above example).

NOTE: this workaround works for form view, but not for list views. The value will still show up for the dependent field in list view. To deal with that, add a 'list_edit' ACL on the substate field (to prevent updates) or a business rule that validates the value selected by the user when trying to save; aborting the transaction when the selected value is not eligible; Hiding the unwanted value from list view is not possible.

KB0635189 shows an additional suggestion for using the removeOption with dependent fields (it needs a timeout so it gets run after the dependent values are built).



Related Problem: PRB590271