[TYPO3-core] RFC #8279: Bug: Sorting in fields of type "group", "MM=1" and "multiple=1" is not preserved

[Ernesto Baschny [cron IT]]

This is an SVN patch request.

Type: Bugfix

Bugtracker references: http://bugs.typo3.org/view.php?id=8279

ChangeSet reference for the fix by Kasper in TYPO3_4-2: 
http://code.typo3.org/v4/changeset/3002

Branches: TYPO3_4-1

Problem:
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=xxx" 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 (sorting=3 twice). To sum up, I cannot 
separate the same uids: they will end up always being sorted in a "block".


Problem:
The problem comes from t3lib_loaddbgroup::writeMM(), which cannot handle 
"multiple=1".

Imagine $oldMMs: 45, 44, 44 (the old order)
the new $this->itemArray in t3lib_loaddbgroup::writeMM() is: 44, 45, 44 
(the desired new order)

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:
In case of multiple=1, delete all records before we start and just write 
the new ones in the order they come in (with INSERT). Attached patch 
does that.


Note:
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.

BTW that new feature (see Kasper's ChangeLog) hasn't been documented and 
is not listed in 
http://wiki.typo3.org/index.php/Pending_Documentation#doc_core_api. 
Should I add it there?

Cheers,
Ernesto

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug8279-groupmultipleMM-v10.diff
Type: text/x-diff
Size: 2354 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20080428/e7a56d64/attachment-0001.diff