Bug #90212
openupdateObject() can loose data when handling related objects
0%
Description
When inserting a new object which has new relating objects attached, updateObject() is called more than once to amend data to the new objects.
If the related object is translateable, and has the fields configured, _localizedUid can already be 0 in the object, which is then tested as true not being null in typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php Line 932 (Typo3 9.5), overwriting the uid with 0 in the following line effectively generating an update-query to uid=0 which of course fails silently.
In the scenario where this popped up I had the loss of data ranged from the pid not set on the related data-row up to complete relation information missing in the related data-row, like 'tablenames','fieldname' and 'uid_foreign' - effectively destroying the relation.
casting the value of $object->_getProperty('_localizedUid') to int and testing for !== 0 will fix this issue:
--- Backend.php 2020-01-26 18:47:11.000000000 +0100 +++ private/typo3/sysext/extbase/Classes/Persistence/Generic/Backend.php 2020-01-26 18:47:34.000000000 +0100 @@ -929,7 +929,7 @@ $row['uid'] = $object->getUid(); if ($dataMap->getLanguageIdColumnName() !== null) { $row[$dataMap->getLanguageIdColumnName()] = (int)$object->_getProperty('_languageUid'); - if ($object->_getProperty('_localizedUid') !== null) { + if ((int)$object->_getProperty('_localizedUid') !== 0) { $row['uid'] = $object->_getProperty('_localizedUid'); } }
the concrete example was the generation of sys_file_references from uploaded files. The PID was never set correctly because of that, and when handling multiple files with ObjectStorages the relation-data was missing because of the problem above