Bug #68624
closedInvalid handling of TCA config "l10n_mode" in the backend for "mergeIfNotBlank"
100%
Description
I think i might have found a small backend bug for the list module, for records that are localised and their TCA config is set to "l10n_mode" => "mergeIfNotBlank".
For an extbase model we have the following TCA config for the "name" field:
'name' => array( 'exclude' => 0, 'l10n_mode' => 'mergeIfNotBlank', 'label' => 'LLL:EXT:fhhwebsite/Resources/Private/Language/locallang_db.xml:tx_fhhwebsite_domain_model_timepiece.name', 'config' => array( 'type' => 'input', 'size' => 32, 'max' => 255, 'eval' => 'trim,required' ), ),
Please note the setting "l10n_mode" with the value "mergeIfNotBlank".
This setting gives me the following list view in the backend, which is wrong:
The following is what I should see:
This happens because the call replaceL10nModeFields inside TYPO3\CMS\Backend\Utility\BackendUtility is wrong...
The line concerned is 1956 (in typo3 6.2.13)
Currently this is what the method is doing:
if ($l10n_mode === 'exclude' || ($l10n_mode === 'mergeIfNotBlank' && trim($originalRow[$field]) !== '')) { $row[$field] = $originalRow[$field]; }
while it should do the opposite
if ($l10n_mode === 'exclude' || ($l10n_mode === 'mergeIfNotBlank' && trim($row[$field]) == '')) { $row[$field] = $originalRow[$field]; }
$originalRow contains the parent data, so the "default" language values, while $row contains the localised version. So if the setting "mergeIfNotBlank" is set, we should check if the localised row $field is empty, if it is then we get the value from the default language, so we compare the localised version, not the original one.
At least this is what I understood from the official docs that should be the behaviour of "mergeIfNotBlank": http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Index.html#l10n-mode
Files
Updated by Christian Kuhn over 9 years ago
can be fixed with part of the change that was done for 7:
https://review.typo3.org/#/c/42050/2/typo3/sysext/backend/Classes/Utility/BackendUtility.php
this part of the 7 change should be safe for a 6.2 backport.
be aware that the tests need adaption as well:
https://review.typo3.org/#/c/42065/2/typo3/sysext/backend/Tests/Unit/Utility/BackendUtilityTest.php
Updated by Christian Kuhn over 9 years ago
btw: thanks for a very well documented and explained issue description!
Updated by Gerrit Code Review over 9 years ago
- Status changed from New to Under Review
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/42121
Updated by Christian Kuhn over 9 years ago
- Target version set to 6.2.15
- Sprint Focus set to Stabilization Sprint
Updated by Christian Kuhn over 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 931f8ad263acf91b416de2fc997e5bcaee0981e6.
Updated by Timo Pfeffer almost 8 years ago
Radu Mogos wrote:
I think i might have found a small backend bug for the list module, for records that are localised and their TCA config is set to "l10n_mode" => "mergeIfNotBlank".
For an extbase model we have the following TCA config for the "name" field:
[...]
Please note the setting "l10n_mode" with the value "mergeIfNotBlank".This setting gives me the following list view in the backend, which is wrong:
The following is what I should see:This happens because the call replaceL10nModeFields inside TYPO3\CMS\Backend\Utility\BackendUtility is wrong...
The line concerned is 1956 (in typo3 6.2.13)
Currently this is what the method is doing:
[...]
while it should do the opposite
[...]$originalRow contains the parent data, so the "default" language values, while $row contains the localised version. So if the setting "mergeIfNotBlank" is set, we should check if the localised row $field is empty, if it is then we get the value from the default language, so we compare the localised version, not the original one.
At least this is what I understood from the official docs that should be the behaviour of "mergeIfNotBlank": http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Index.html#l10n-mode
The Ticket should be reopened, because the fix does only work for string fields and not for integers. it makes sense to merge a field, if its value is not 0. so please change the === '' check in the code to a == '' to handle it correctly.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed