Issue Summary

This is reproducible on Data Center: yes

When cascadeOption() is used in the filter, with referencing of option ID, the filter is broken after the migration.

For example this JQL:

project = SPRINT AND cf[10507] in cascadeOption(10420, 10423) 

• 10420 & 10423 are IDs from Server

Steps to Reproduce

1. Create a custom field with "Select List (cascading)" type
2. Associate the field and value to a project
3. Create a filter with cascadeOption() and reference the values in ID instead of name
4. Migrate the filter to the cloud

Expected Results

The filter is updated with the Option ID

Actual Results

The filter remains pointing to the old Option ID. The filter displays invalid or incorrect data.

• After the migration, custom field value is automatically updated but the Option ID aren't.
  • JQL before the migration:

    project = SPRINT AND cf[10507] in cascadeOption(10420, 10423) 

• • JQL after the migration:

    project = SPRINT AND cf[10101] in cascadeOption(10420, 10423)
    

Workaround

• Option 1: Use Option Name instead ID in the function
• Option 2: Update the filter manually.

Support may help to retrieve the IDs from the destination Cloud site:

select cf.id as customfield_id, cf.cfname as customfield_name,parent.id as parent_option_id,parent.customvalue as parent_value,child.id as child_option_id,child.customvalue as child_value
from customfield cf
join customfieldoption parent on cf.id=parent.customfield
left join customfieldoption child on child.parentoptionid=parent.id
where cf.customfieldtypekey='com.atlassian.jira.plugin.system.customfieldtypes:cascadingselect'
order by cf.id,parent_option_id,child_option_id;