Bug #71293
closedStory #69712: Further FormEngine development
`foreign_record_defaults` is not stored when the field hidden
0%
Description
You have the two tables tx_enterprise_domain_model_address
with three different types of addresses (phone
, email
and postal
). Per default the type
select is visible in all types.
array( 'ctrl' => array( [...] 'type' => 'type', [...] ), 'types' => array( '0' => array( 'showitem' => ' --palette--;;general, --palette--;;postal, --palette--;;phone, [...] ' ), 'postal' => array( 'showitem' => ' --palette--;;general, --palette--;;postal ' ), 'phone' => array( 'showitem' => ' --palette--;;general, --palette--;;phone ' ), 'email' => array( 'showitem' => ' --palette--;;general, --palette--;;email ' ), [...] ), 'palettes' => array( 'general' => array( 'showitem' => ' type ' ), 'postal' => array( 'showitem' => ' street, [...] ' ), 'phone' => array( 'showitem' => ' phone, [...] ' ), 'email' => array( 'showitem' => ' email, [...] ' ), [...] ), 'columns' => array( [...] 'type' => array( [...] 'config' => array( 'type' => 'select', 'default' => 'postal', 'items' => array( array( 'Postal', 'postal' ), array( 'Phone', 'phone' ), array( 'Email', 'email' ), [...] ) ) ) [...] ) );
And you have the table tx_enterprise_domain_model_person
with the two columns phones
and emails
. In phones
the inline record address has no type select (see its foreign_types
) but emails
leaves this as configured in the inline record table above.
array( [...] 'columns' => array( [...] 'phones' => array( [...] 'config' => array( 'type' => 'inline', 'foreign_table' => 'tx_enterprise_domain_model_address', 'foreign_types' => array( 'phone' => array( 'showitem' => ' --palette--;;phone ' ) ), 'foreign_record_defaults' => array( 'type' => 'phone' ), [...] ) ), 'emails' => array( [...] 'config' => array( 'type' => 'inline', 'foreign_table' => 'tx_enterprise_domain_model_address', 'foreign_record_defaults' => array( 'type' => 'email' ), [...] ) ) ) );
After creating a person and adding a new phone number and a email for that person, you see for each inline record the correct form; for phones
this is only the input for a phone number, for emails
this is the type
select and a input for the email itself. But after saving the type
value for the phones
inline record is postal
and not phone
. So in this case foreign_record_defaults
is only correctly stored when the corresponding field was rendered before. But the expectation would be that all values in foreign_record_defaults
are stored in any case no matter if they rendered before or not.
Updated by Wouter Wolters about 9 years ago
- Assignee deleted (
Mathias Schreiber)
Updated by Christian Kuhn about 9 years ago
hmm ... this is not an issue that is new in 7, right? it has always been like that in 6.2 as well if i'm not mistaken?
Updated by Artus Kolanowski about 9 years ago
- Assignee set to Mathias Schreiber
@Christian Kuhn I was afraid that this is might be not a regression. But I can't tell for sure, haven't tested this in TYPO3 CMS 6.
Updated by Christian Kuhn about 9 years ago
ok, thinking about that, here is the whole picture:
for "usual" rows that are not in an inline relation where parent sets foreign_record_defaults, the same issue would happen. But it does not, because fields that have default values but are also not rendered and thus their values not transferred, BUT the DataHandler (i guess, didn't dig into) probably applies "default" config again if creating a new row and no value is set.
For inline with foreign_record_defaults this does not happen in DataHandler (DH does not know about the parent state with these details), the field is not rendered, value not transferred and DataHandler just sets the value to the default defined for the child tca field if given.
The fun part is that FAL suffers from the same issue: FAL relations have a couple of fields in a "filePalette" (uid_local, hidden, sys_language_uid, l10n_parent) and this palette is set to "isHiddenPalette = TRUE". This way, those fields are always rendered and transferred, but never shown.
While this "solution" is hilariously ugly, it will solve your issue for now by just creating such a hidden palette, too and adding "type" to it.
The "real" solution is do-able within the data provider of FormEngine: Add "columnsToProcess" array with fields that have defaults but are not within showitems/palettes within one of the according data providers. next, append those fields to showitem and override their processedTca to renderType=hidden. The default values itself are already set by one of the default value data providers. Thus, you'll end up with an additional hidden field per not-rendered field. In effect, probably the "hidden palette" stuff can be finally removed, reducing the FAL HTML overhead quite a bit, and the dataHandler could get its default handling removed and we could deprecate the "isHiddenPalette" stuff.
Updated by Christian Kuhn about 9 years ago
So, your issue can be solved with a hack similar to the FAL hack, while the real issue should be solved within core later.
Updated by Christian Kuhn about 9 years ago
- Category set to FormEngine aka TCEforms
lets see if we can manage to get a patch in until final.
Updated by Artus Kolanowski about 9 years ago
@Christian Kuhn Thank you very much! I totally agree!
Updated by Susanne Moog over 4 years ago
- Status changed from New to Closed
Since there were no further reports of this issue and there is an existing workaround, I'm going to close this issue now - if those parts get refactored at a later point by the datahandler intiative, these issues can be revisited.