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

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:

Table B extends table A Table A has a 'state' field and a 'substate' field. Those fields are inherited by table B. Both are based on sys_choice for the choicelist The substate field is dependent on the state field. So values for substate are displayed based on the selected value for state Now new values are added for substate specifically for table B, dependent on one of the values for state. 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).