Bug #17255

Combined mode doesn't work with type 'group'

Added by David Bruehlmeier about 12 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2007-04-27
Due date:
% Done:

0%

TYPO3 Version:
4.1
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When using the 'useCombined' = true option (in appearance), the child record is not displayed when the field type on the intermediate table is 'group' instead of 'select'.

(issue imported from #M5514)

0005514.patch View (3.66 KB) Administrator Admin, 2007-04-27 20:21

0005514_v3.patch View (8.32 KB) Administrator Admin, 2007-05-12 23:18

0005514_v4_41.patch View (10.6 KB) Administrator Admin, 2007-06-26 09:03

0005514_v4_trunk.patch View (11.1 KB) Administrator Admin, 2007-06-26 09:04


Related issues

Related to TYPO3 Core - Bug #17374: Combination mode doesn't save new child records correctly Closed 2007-06-11
Related to TYPO3 Core - Bug #17394: Child records are displayed multiple times: using patch 5718 Closed 2007-06-18
Related to TYPO3 Core - Bug #18646: Combination view not possible with symmetric relations Closed 2008-04-19
Related to TYPO3 Core - Bug #43242: The "foreign_selector" in IRRE fields does not work with foreign group field New 2012-11-23

History

#1 Updated by Oliver Hader about 12 years ago

I can confirm this bug.

#2 Updated by Oliver Hader about 12 years ago

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

#3 Updated by David Bruehlmeier about 12 years ago

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

#4 Updated by Oliver Hader about 12 years ago

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

#5 Updated by Oliver Hader about 12 years ago

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.

<b>There are still some things on the TODO list for the combined mode:</b>
  • 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>

#6 Updated by Oliver Hader about 12 years ago

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

#7 Updated by Oliver Hader about 12 years ago

I implemented some more changes as mentioned before:
  • 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

#8 Updated by David Bruehlmeier about 12 years ago

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>

#9 Updated by Oliver Hader over 6 years ago

  • Category set to 978
  • Target version deleted (0)

#10 Updated by Alexander Opitz about 6 years ago

  • Status changed from Accepted to Needs Feedback

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

#11 Updated by Alexander Opitz almost 6 years ago

  • Status changed from Needs Feedback to Closed
  • Assignee deleted (Oliver Hader)

No feedback for over 90 days.

Also available in: Atom PDF