Bug #18721
closedSorting in fields of type "group", "MM=1" and "multiple=1" is not preserved
0%
Description
If I have a field defined like:
'mitglieder_ag' => array(
'exclude' => 1,
'label' => 'LLL:EXT:cronmm_ratsinfo/locallang_db.xml:tx_cronmmratsinfo_gremium.mitglieder_ag',
'config' => array(
'type' => 'group',
'internal_type' => 'db',
'allowed' => 'tx_cronmmratsinfo_ausschussgemeinschaft',
'size' => 20,
'minitems' => 0,
'maxitems' => 100,
'multiple' => 1,
'selectedListStyle' => 'width:100px',
'MM' => 'tx_cronmmratsinfo_gremium_mitglieder_ag_mm',
)
),
that is with "MM=1" and "multiple=1", I am able to have a list where the same record occurs multiple times, e.g:
uid_foreign=45, sorting=1
uid_foreign=44, sorting=2
uid_foreign=44, sorting=3
After moving the entry 45 down one item (to get the list "44, 45, 44"), and I save the record, I end up with the following list:
45, sorting = 1
44, sorting = 3
44, sorting = 3
So not the desired sorting. I cannot separate the same uids: they will end up always being sorted in a "block".
The problem comes from t3lib_loaddbgroup::writeMM(), which cannot handle "multiple=1".
oldMMs:
45, 44, 44
the new itemArray in t3lib_loaddbgroup::writeMM():
44, 45, 44
In t3lib_loaddbgroup::writeMM() TYPO3 will execute the following UPDATEs:
UPDATE tx_cronmmratsinfo_gremium_mitglieder_ag_mm SET sorting = 1 WHERE uid_local=1026 AND uid_foreign=44
UPDATE tx_cronmmratsinfo_gremium_mitglieder_ag_mm SET sorting = 2 WHERE uid_local=1026 AND uid_foreign=45
UPDATE tx_cronmmratsinfo_gremium_mitglieder_ag_mm SET sorting = 3 WHERE uid_local=1026 AND uid_foreign=44
Notice that the last UPDATE will override what the first one did, so that we end up with the MM-table containing:
45, sorting = 2
44, sorting = 3
44, sorting = 3
and we would expect:
44, sorting = 1
45, sorting = 2
44, sorting = 3
Solution for "multiple=1" is to delete all records before we start and just write the new ones in the order they come in (with INSERT).
(issue imported from #M8279)
Files
Updated by Ernesto Baschny over 16 years ago
The problem is not present in TYPO3 4.2, because of this change done by Kasper in January: http://code.typo3.org/v4/changeset/3002. The solution here was to add a "uid" field for every MM table that needs "multiple=1", to be able to identify each record uniquely even if they contain the same uid_local/uid_foreign combination. I would like to fix the bug in 4.1 like suggested above, because else we would have to backport a new feature from 4.2 (new TCA setting "MM_hasUidField") to 4.1.
Updated by Ernesto Baschny over 16 years ago
Committed to TYPO3_4-1 (rev. 3768).