TYPO3 Core

I can confirm this bug.

The attached patch file should resolve this issue.
The TCA type group/db wasn't rendered at all for the combined view.

Hi Olly,

I have applied the patch and the child form is now correctly rendered. Unfortunately, the entered data doesn't seem to get saved. :-(

Have a nice evening!
Dave

You're right. It seems, like I have to work again on the patch. Sorry for it...

Sorry, for the delay. I is/was a bit more work the expected at the beginning. The problem is that select and group handle identifiers differntly - e.g. has as group field something like this "tx_myext_table_1234" which has to be treated in a special way - also in TCEmain in consideration of remapping.

• there is a error in htmlspecialchars (or something like this) in the header labels of children
• combined view without uniqueness doesn't make much sense, you cannot add the same record twice and edit each of them separately in on form
• the required fields are not updated/removed correctly if a virtual child record was removed again without saving ever
• importing an existing child record via selector, removing it and importing it again might cause some trouble (without saving the record at all)

<b>The attached patch enables group/db fields with the combined mode - but with the general exceptions from above.</b>

As the bugs #17374 and #17374 show, it's necessary to use uniqueness automatically if the combined mode is used.

• if using a selector and the combined mode, uniqueness will be set automatically (it's not possible to edit the same record twice)
• the required fields of the combined part in TBE_EDITOR are removed now correctly

0005514_v4_41.patch is for the TYPO3 4.1 branch
0005514_v4_trunk.patch is for the TYPO3 4.2dev (Trunk) branch

Thanks a lot for the new patch! I have tested it with the Party Information Framework, here's the result:

<ul>
<li>IRRE now works properly with the type 'group'. I have testet the creation of new child records (both on saved and non-saved parent records) as well as the linking of existing child records using the element-browser (also on both saved and non-saved parent records)</li>
<li>I also tested the deletion of child records in several ways and found no errors.</li>
<li>I can confirm the error with the HTML chars in the title, as described in the bug notes.</li>
<li>I can see why the new restriction regarding "uniqueness" is technically useful, but from a user's perspective, that's not really nice. Example from the Party Information Framework: An address is related to a party with a certain usage. For instance a company might have a legal seat and a delivery address. Both addresses might be the same, just with a different usage (the usage is an attribute on the mm-table). This use case could not be realized with the uniqueness-restriction. Of course I understand that in the described case, there is a problem when a user makes changes to both addresses in the form which are actually the same address. So there would need to be a way to work around that. Still I feel that it should be up to the extension developer to decide whether or not uniqueness is right for the use case at hand.<br><br>Suggestion: If <b>no</b> uniqueness is wanted, only the fields of the first record could be made editable, the fields of all the following (identical) records could be rendered read-only.</li>
</ul>