If a glide.list field created on one instance is transferred via update set to another instance, its sys_storage_alias record is not pointing to the correct database field. Instead of pointing to a medium text field it points to a varchar field. Because this field now allows only one sys_id to be stored, adding multiple items to the list is not possible.
Steps to Reproduce
- Create a new update set and set it as current.
- Create a List type field on Incident table referencing Users table with max_length = 32.
- Check sys_storage_alias and confirm that on the database, it is linked to a field on task table defined as mediumtext.
- Complete the update set and transfer it to another instance.
- Check the sys_storage_alias and see whether it has been linked to a field on the database defined as anything other than mediumtext, for example, varchar(32).
This issue is fixed in all currently supported versions. If on a pre-Istanbul instance, in order to fix an already affected field, please open an incident for SN support to apply the required dictionary change.
In order to prevent the issue on an instance not yet upgraded, create a BEFORE INSERT and UPDATE business rule on sys_dictionary of source and target instances with:
- Order: between 50 and 100
- Advanced: true
- Condition: current.internal_type == 'glide_list' && current.max_length < 256
- Script: current.max_length = 4000;
This will prevent the issue by creating an update set entry with correct max_length on the source instance and also ensure correct creation or an update of a Dictionary record manually or when an update set is committed on a target instance.
Related Problem: PRB645057