Bug #70523


Story #69617: FormEngine bugs

processForeignTableClause in case of array should be a comma separated list (e.g. MM relations)

Added by Andreas Allacher almost 9 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:


With this change

processed select values are partly handled but the array could contain multiple values, e.g. because of MM relations or so which then should be handled as comma separated list (which was how it was done prior to FormEngine change).

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #69952: processForeignTableClause fails when used with select fieldsClosed2015-09-18

Actions #1

Updated by Christian Kuhn almost 9 years ago

  • Parent task set to #69617
Actions #2

Updated by Christian Kuhn almost 9 years ago

  • Assignee deleted (Christian Kuhn)
Actions #3

Updated by Christian Kuhn over 8 years ago

  • Category changed from Backend API to FormEngine aka TCEforms
Actions #4

Updated by Mathias Schreiber over 8 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Mathias Schreiber

Are you sure about this?
The change refers to ###REC_FIELD_ so you get the value of that field.

In case of MM tables it will always have returned the number of relations, not a CSV of their uids.
We could change it to $rowFieldValue = implode(',', $rowFieldValue); in order to make the CSV available, but I still doubt it makes sense this way.

Do you have some TCA at hand that would illustrate the faulty behavior?

typo3/sysext/backend/Classes/Form/FormDataProvider/AbstractItemProvider.php Line 977

Actions #5

Updated by Andreas Allacher over 8 years ago

Yes, I meant MM relations or also non MM but with multiple values stored in one field.
In the first case as you mentioned it previously returned the count - which didn't make sense - and now it returns the first value only which also doesn't make sense I think.

Regarding multiple values stored in one field that was stored as CSV and would therefore have been CSV and now it would be an array of values which only returns one value.

Honestly I think it should return a csv if used in combination with IN but the first value if used in combination with =
Although I think that might not be so easy to achieve.

Actions #6

Updated by Christian Kuhn about 8 years ago

change referenced by andreas:

Actions #7

Updated by Christian Kuhn about 8 years ago

  • Status changed from Needs Feedback to Rejected

Mmmmmh, I'll close this one as rejected:

Having a select field that uses a foreign_table_where with a marker that injects the value from a field of the same row into the query isn't really very much common and a complex scenario already. Now the reference value itself is a select or group that then again references different tables and has potentially multiple values. And now this request is about adding magic that manipulates the current values again to try do do something sane with it. This is complexity level 'close to hell'.

Honestly, I think we should say that a ###REC_FIELD_ marker should NOT refer to a multi value field, but to single value fields only. This is what is done at the moment and it overstrains most people already.

Furthermore, there is always the possibility to use an itemsProcFunc - a solution I'd prefer for such use cases, the php code would be much easier to understand than the details of this magic marker substitution foo.

Actions #8

Updated by Christian Kuhn about 8 years ago

  • % Done changed from 0 to 100

Also available in: Atom PDF