Bug #82221
openCopying records with "flex" fields containing FAL IRRE relations fails to move copies to new parent upon workspace publishing
0%
Description
Prerequisites:
- Content element with flexform
- At least one field of type "inline" wanting FAL references
- A draft workspace
Reproduction, first symptom:
- Switch to live workspace
- Create an instance of the content type
- Fill in at least one FAL relation, best two or more (count of relations is a symptom and having one single relation may confuse)
- Switch to draft workspace
- Copy the content element, does not matter where to
- Observe first symptom: draft record's "pi_flexform" column contains an incorrect FAL reference value (CSV list of UIDs, or single UID, instead of count). Placeholder record contains the correct FAL reference value (number of references). Copies of file relations in sys_file_reference have the correct uid_local value (pointing to the new, copied record).
- Editing either the original or the copy of the parent record shows the expected relations (note 1)
Reproduction, second symptom:
- Switch to the workspaces module
- Perform publishing of all pending changes
- Observe the second symptom: original record now has double the original file relations and the copy of the parent record has no file relations (uid_local of copies created in sys_file_reference now point to original instead of placeholder)
- Both backend and frontend now display double relations for original record and no relations for copy of record (note 2).
Notes:
- Note 1: The expected relations are resolved from the placeholder record which has the correct values, so the GUI shows these relations correctly but the DB data is corrupted.
- Note 2: The incorrect values get set as part of the "publish workspace" step. The column is NOT in the list of shadow columns (but adding it makes no difference).
Solution:
The solution appears to be adding the UID of the newly created placeholder record as target UID in the substNEWwithIDs array in DataHandler. This one line of code causes both of the symptoms to disappear - the correct relationship UID is then read from the placeholder record and translated to the UID of the copy of the parent record. The code comment immediately outside the condition that checks if a placeholder was created even states that the UID gets recorded, but that currently is not the case. Adding the UID does exactly that.
Issue may exist as far back as TYPO3 7.6 but has been tested on 8.7 and master only. Both exhibit the same symptoms.
Files