Feature #19443

Localization of IRRE-children for n:m relations with useCombination=1

Added by Alexander Bohndorf about 11 years ago. Updated over 1 year ago.

Status:
New
Priority:
Could have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2008-10-09
Due date:
% Done:

0%

PHP Version:
5.0
Tags:
Complexity:
Sprint Focus:

Description

related to #0006087

Is it planned to extend the localization feature of IRRE for n:m relations in useCombination=1 mode?
We have the following database model (n:m relation, intermediate table with additional fields beside the foreign keys):
1 person has many projects. A project has many persons. A person has a special role in a project. Therefore we have 3 tables: person -- person-project -- project. The role is a field in the person-project table.

In the person we have IRRE-fields for person-project records with useCombination=1. So you can edit the role (field in person-project) and also you can edit the project in the person record.
With the localization mode "select" you can translate the person-project records with the button "synchronize". The problem is now, that all the created localized person-project records reference correctly to the localized person record but to the projects in the default language what is definitely wrong.

Instead the projects should also have been localized when pressing the "synchronize"-Button.

Looking at the other side: Editing projects and inside the projects the related persons:
Localizing the related project results and pressing the "syncronize" button in the localized records results in new localized person-project records with reference to the correct localized project but the wrong reference to the persons in the default language.

The missing feature is a way to handle localization for editing the m:n relations from each side via IRRE (from persons or from projects), resulting in person-project records where both foreign keys reference correctly to the localized projects and persons.

I tried also to define the foreign keys in person-project as l10n_mode=>'exclude', because the relation between persons and projects is the same in translation as in the original language. When I clicked "synchronize" in person, it results in creating new project records in the default language, this is a misbehaviour.

here is our tca:
$TCA["tx_smshisdb_person"] = array (
"project" => Array (
"exclude" => 0,
"label" => "LLL:EXT:sms_his_db/locallang_db.xml:tx_smshisdb_person.project",
"config" => Array (
"type" => "inline",
"foreign_table" => "tx_smshisdb_person_project",
"foreign_field" => "uid_person",
"foreign_label" => "uid_project",
"appearance" => Array (
"useCombination" => 1,
'showSynchronizationLink' => 1,
'showAllLocalizationLink' => 1,
'showPossibleLocalizationRecords' => 1,
'showRemovedLocalizationRecords' => 1,
),
'behaviour' => array(
'localizationMode' => 'select',
'localizeChildrenAtParentLocalization' => 1,
),
"foreign_selector" => "uid_project",
"foreign_unique" => "uid_project",
)
),
),
);

$TCA["tx_smshisdb_person_project"] = array (
"uid_person" => Array (
"exclude" => 0,
"label" => "LLL:EXT:sms_his_db/locallang_db.xml:tx_smshisdb_person_project.uid_person",
"config" => Array (
"type" => "select",
"foreign_table" => "tx_smshisdb_person",
"foreign_table_where" => " AND tx_smshisdb_person.sys_language_uid=###REC_FIELD_sys_language_uid### ORDER BY tx_smshisdb_person.nachname",
"size" => 1,
"minitems" => 0,
"maxitems" => 1,
)
),
"uid_project" => Array (
"exclude" => 0,
"label" => "LLL:EXT:sms_his_db/locallang_db.xml:tx_smshisdb_person_project.uid_project",
"config" => Array (
"type" => "select",
"foreign_table" => "tx_smshisdb_project",
"foreign_table_where" => " AND tx_smshisdb_project.sys_language_uid=###REC_FIELD_sys_language_uid### ORDER BY tx_smshisdb_project.uid",
"size" => 1,
"minitems" => 0,
"maxitems" => 1,
)
),
"role" => Array (
"exclude" => 0,
"label" => "LLL:EXT:sms_his_db/locallang_db.xml:tx_smshisdb_person_project.role",
"config" => Array (
"type" => "input",
"size" => "30",
)
),
);

$TCA["tx_smshisdb_project"] = array (
"person" => Array (
"exclude" => 0,
"label" => "LLL:EXT:sms_his_db/locallang_db.xml:tx_smshisdb_project.person",
"config" => Array (
"type" => "inline",
"foreign_table" => "tx_smshisdb_person_project",
"foreign_field" => "uid_project",
"foreign_label" => "uid_person",
"appearance" => Array (
"useCombination" => 1,
"expandSingle" => 1,
"collapseAll" => 1,
'showSynchronizationLink' => 1,
'showAllLocalizationLink' => 1,
'showPossibleLocalizationRecords' => 1,
'showRemovedLocalizationRecords' => 1,
),
"foreign_selector" => "uid_person",
"foreign_unique" => "uid_person",
"behaviour" => Array (
"localizationMode" => "select",
),
),
),
);
(issue imported from #M9526)

History

#1 Updated by Alexander Bohndorf almost 11 years ago

this behaviour can be solved with the following TCA in the config-array for the intermediate table fields uid_person and uid_project:

"localizeReferencesAtParentLocalization" => 1,

but there is still another bug:

"localizeReferencesAtParentLocalization" => 1,
does not work together with
"config"/"behavior"/"localizeChildrenAtParentLocalization" => 1 for the field "project" in table tx_smshisdb_project". If you try to localize a project with this configuration it results in an empty form (ajax response error).

#2 Updated by Alexander Opitz over 6 years ago

  • Status changed from New to Needs Feedback
  • Target version deleted (0)

The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?

#3 Updated by Alexander Opitz about 6 years ago

  • Status changed from Needs Feedback to Closed

No feedback for over 90 days.

#4 Updated by Claus Due over 2 years ago

  • Status changed from Closed to Accepted

Revived, a solution has been found. Patch coming shortly!

#5 Updated by Susanne Moog almost 2 years ago

  • Category set to DataHandler aka TCEmain
  • Status changed from Accepted to Needs Feedback
  • Assignee set to Claus Due

Claus, are you still working on this?

#6 Updated by Oliver Hader almost 2 years ago

  • Priority changed from Should have to Could have

#7 Updated by Alexander Opitz over 1 year ago

  • Status changed from Needs Feedback to New
  • Assignee deleted (Claus Due)

Response from Claus on Slack: "nope - patch ended up with side effects and never got submitted"

Also available in: Atom PDF