Bug #23734


Multiple problems with using combinations of foreign_selector, foreign_unique and useCombination

Added by Philipp Kerling over 13 years ago. Updated about 8 years ago.

Should have
FormEngine aka TCEforms
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


IRRE presents several problems when using certain combinations of the foreign_selector, foreign_unique and useCombination properties in asymmetric m:n relations.

Everything works as expected if foreign_selector and foreign_unique have the same value and useCombination is set to true.
If useCombination is disabled, IRRE fails to save the relation records to the database. All relation records get saved with the field pointed to by foreign_field set to 0 instead of the real value. I have attached a workaround that works for me, but I am unsure as to whether it is the right way to approach this issue since I don't know a lot about IRRE.
If useCombination is disabled and foreign_unique is set, dynamically added elements are not removed from the foreign_selector (fixed by #21102).
If useCombination is enabled and foreign_unique is not set, saving the relations fails with the same symptoms as above, but I have not looked into why.

I have attached a small extension to test this, steps to reproduce:
- Install extension and create the tables
- Create and save a new element of "Sub Table" in a sysfolder
- Create a new element of "Main Table" in the same sysfolder
- Add a relation to the sub element to the main element
- Save
The relation should now be displayed as "[No title]" instead of the actual sub element.

(issue imported from #M15996)


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #23608: m:n asymetric combo: relations loose data on savingClosedMathias Schreiber2010-09-25

Related to TYPO3 Core - Bug #23838: Insert via combobox failsClosedChris topher2010-10-25

Related to TYPO3 Core - Bug #21102: IRRE: Selected items not removed from selector when foreign_unique is setClosedStanislas Rolland2010-08-09

Actions #1

Updated by Julian Hofmann over 13 years ago

Related to #0016126, #0015804

Actions #2

Updated by Philipp Kerling over 12 years ago

  • Target version deleted (0)

Still unpatched in 4.5.3, patch also still works

Actions #3

Updated by Stefan Galinski almost 11 years ago

  • Category set to 978
Actions #4

Updated by Mathias Schreiber about 9 years ago

  • Target version set to 7.4 (Backend)
  • Is Regression set to No
Actions #5

Updated by Susanne Moog over 8 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #6

Updated by Benni Mack over 8 years ago

  • Target version deleted (7.5)
Actions #7

Updated by Morton Jonuschat about 8 years ago

  • Status changed from New to Closed

Closing this as I can't reproduce it using the test extension (updated for 7 LTS) on the latest master. Probably has been solved with the FormEngine rewrite.


Also available in: Atom PDF