This LPS is something of a continuation of
LPS-69595. The bug from LPS-69595, due to the nature of how it works, may corrupt DDLRecords by causing the _fieldsDisplay field to be empty. This corruption will cause any import with these DDLRecords to fail, because the corrupted DDLRecords cannot be merged with imported ones without the _fieldsDisplay field.
The VerifyDynamicDataMapping VerifyProcess in ee-6.2.x can detect and regenerate _fieldsDisplay fields when there is none, but fails to detect a problem if the _fieldsDisplay field has lost its value from this bug. It should be able to detect this and regenerate the field in the same way.
There does not appear to be a way to successfully upgrade the DDL module to DXP when this corruption is present in the database, so that appears to be a different bug for master/DXP that should be handled separately, possibly with its own UpgradeProcess.
i. Create a new site
ii. Within the new site, create a DDMStructure with at least one field of any data type
iii. Create a Dynamic Data List and DDLRecord based on this structure
iv. Go to Site Pages -> Export as LAR, and download the LAR
v. Delete the Dynamic Data List (necessary for deleting the site because of the existing bug,
vi. Delete the site
vii. Create a new blank site
viii. Go to Site Pages -> Import the LAR three times (at this point the DDLRecords now have corrupted _fieldsDisplay fields)
Expected result: administrators can run a built-in Liferay process to repair DDLRecords (i.e., a VerifyProcess)
Actual result: administrators have no built-in Liferay processes to repair DDLRecords