Update for ChoiceType field via PATCH HTTP method doesn't work

[ostrolucky]

Form having only one field (choiceType) works fine if sent as POST, but doesn't if same data are sent as PATCH. Tested on symfony 2.7.9 and 3.0.2.

[HeahDude]

Hi @gadelat, with a PATCH method, $clearMissing is false when submitting, see :
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/NativeRequestHandler.php#L129
So it may be related to #16802, could you please try the fix of this pending PR #17771 ?

[HeahDude]

I can confirm your bug as of 2.7, but even if the the fix provided by #17771 might work, I've experience the same experience as you with validation.

We cannot close this one as duplicate of #16802 yet since in your case the proper fix would be :

elseif (!$isSubmitted && !$clearMissing && array_key_exists($name, $submittedData) && 'placeholder' != $name) {
    $child->submit($submittedData[$name], $clearMissing);
}

Note that the validation does fail but the data has been updated anyway.

Errors are showing up in wdt if choices before matching the submitted one were unsuccessful.

I can't get a way to fix both issue at the same time, my test here does fail with the above code.

Has anyone got a clue ?

[HeahDude]

Ok I think I found a proper way to fix it, could you please try to add this at line 560 of Form :

$clearMissing = $this->getConfig()->getOption('expanded', false) ?: $clearMissing;

[ostrolucky]

Works for both Symfony 2.7 and Symfony 3

[HeahDude]

Thank you for your feedback.

[HeahDude]

"unconfirmed" label should be removed.

Status: reviewed

[Silverspur]

I found this thread looking for a solution of the tackled issue in the case of a expanded+multiple choice field (array of checkboxes). The patch clearly solves the problem in this case, but I'm also wondering how to deal with a single checkbox, which is not solved here.

Since $clearMissing is false, the submission of a form with an unchecked checkbox won't make its related data flip from true to false. I see one solution, i.e. to systematically explicitly send from the front end a reserved value, like __false, for any unchecked checkbox whose value must be updated, and using in Symfony a data transformer to link this specific value to 'null'. I find this a bit of hacking. Do I miss something obvious?

[HeahDude]

Hi @Silverspur, thank you for your feedback.

You're right at this time, this patch I provided is more like a "hack" to get things working, I'm still looking for a "proper" way to fix this globally.

If you encountered this issue with a single CheckboxType I would suggest you open another issue and provide more information about the steps needed to reproduce your issue.

[leevigraham]

$clearMissing = $this->getConfig()->getOption('expanded', false) ?: $clearMissing;

I fixed my issue by removing 'expanded' => true from my forms.I guess this isn't an option for everyone tho.

[liverbool]

bug confirm: sf ^3.2 (expanded = true)

// \Symfony\Component\Form\Extension\Core\DataMapper\RadioListMapper
public function mapFormsToData($radios, &$choice)
    {
        if (null !== $choice && !is_string($choice)) {
            throw new UnexpectedTypeException($choice, 'null or string');
        }

        $choice = null;

        foreach ($radios as $radio) {
            // fixed by adding: && $radio->isSubmitted()
            if ($radio->getData() && $radio->isSubmitted()) {
                if ('placeholder' === $radio->getName()) {
                    return;
                }

                $choice = $radio->getConfig()->getOption('value');

                return;
            }
        }
    }

[SlKelevro]

Same bug here, SF 3.2.7, but my guess is it's been there for a very long time. Luckily, setting 'expanded' => false works for me, but it's not an option in general. Tried fix from @liverbool ($checkbox->isSubmitted() in CheckboxListMapper in my case) and it seems to work.

Example, just in case:

        $existing  = ['items' => [1, 3]];
        $submitted = ['items' => [2, 4]];

        $builder = $this->createFormBuilder($existing);
        $builder->add(
            'items',
            ChoiceType::class,
            [
                'choices'  => [
                    'One'   => 1,
                    'Two'   => 2,
                    'Three' => 3,
                    'Four'  => 4,
                    'Five'  => 5,
                ],
                'expanded' => true,
                'multiple' => true,
            ]
        );

        $form = $builder->getForm();
        $form->submit($submitted, false);

        var_dump($form->getData()['items']);

Actual:

  0 => int 1
  1 => int 3
  2 => int 2
  3 => int 4

Expected:

  0 => int 2
  1 => int 4

[jr-k]

Still the issue now (3.3), is it possible to include the hack of HeahDude ? Thanks

[Viktor-Bredihin]

any update on this one? The bug request created 3 years ago and still no fix

[xabbuh]

You could be the one to write the fix. I will happily review a pull request.

[carsonbot]

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

[ostrolucky]

yes

[carsonbot]

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

[carsonbot]

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

[magikid-sourceability]

Since Symfony 3.3 is no longer supported, has anyone tested to see if this is still an issue on Symfony 5 or 6?

[connorhu]

This issue is no longer relevant (if SlKelevro's code is correct and the test I wrote is correct).

Test: https://github.com/connorhu/symfony-issue-verify/blob/gh17799/tests/Issues/GH17799Test.php

git clone --branch gh17799 https://github.com/connorhu/symfony-issue-verify && cd symfony-issue-verify && ./init.sh 17799

[ostrolucky]

Indeed, this looks solved now! Closing.