Bug #71293

Story #69712: Further FormEngine development

`foreign_record_defaults` is not stored when the field hidden

Added by Artus Kolanowski almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
Start date:
2015-11-03
Due date:
% Done:

0%

TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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.


Related issues

Related to TYPO3 Core - Bug #70904: IRRE: foreign_record_defaults for colPos gets trimmed Closed 2015-10-21

History

#1 Updated by Wouter Wolters almost 4 years ago

  • Assignee deleted (Mathias Schreiber)

#2 Updated by Christian Kuhn almost 4 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?

#3 Updated by Artus Kolanowski almost 4 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.

#4 Updated by Artus Kolanowski almost 4 years ago

  • Assignee deleted (Mathias Schreiber)

Sorry!

#5 Updated by Christian Kuhn almost 4 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.

#6 Updated by Christian Kuhn almost 4 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.

#7 Updated by Christian Kuhn almost 4 years ago

  • Category set to FormEngine aka TCEforms

lets see if we can manage to get a patch in until final.

#8 Updated by Artus Kolanowski almost 4 years ago

@Christian Kuhn Thank you very much! I totally agree!

#9 Updated by Christian Kuhn almost 4 years ago

  • Parent task set to #69712

Also available in: Atom PDF