Bug #70523
closed
Story #69617: FormEngine bugs
processForeignTableClause in case of array should be a comma separated list (e.g. MM relations)
100%
Description
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).
Updated by Christian Kuhn over 8 years ago
- Category changed from Backend API to FormEngine aka TCEforms
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?
INTERNAL REFERENCE
-----------------------------
typo3/sysext/backend/Classes/Form/FormDataProvider/AbstractItemProvider.php Line 977
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.
Updated by Christian Kuhn almost 8 years ago
change referenced by andreas: http://review.typo3.org/43425
Updated by Christian Kuhn almost 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.