APIResource mess with denormalization for underscore property

[Grafikart]

API Platform version(s) affected: 3.1

Description
I have a model with the following field

<?php

namespace App\Entity;

use ApiPlatform\Metadata\ApiProperty;
use App\Repository\UserRepository;
use App\State\DebugProcessor;
use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Serializer\Annotation\Groups;

#[ORM\Entity(repositoryClass: UserRepository::class)]
#[ORM\Table(name: '`user`')]
class User
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    #[Groups("write")]
    private ?string $username = null;

    #[ORM\Column(length: 255)]
    #[Groups("write")]
    private ?string $first_name = null;

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getUsername(): ?string
    {
        return $this->username;
    }

    public function setUsername(string $username): static
    {
        $this->username = $username;

        return $this;
    }

    public function getFirstName(): ?string
    {
        return $this->first_name;
    }

    public function setFirstName(string $first_name): static
    {
        $this->first_name = $first_name;

        return $this;
    }
}

If I try to denormalize it I get a model filled with all the properties.

        $data = $denormalizer->denormalize([
            'username' => 'John',
            'first_name' => 'Doe',
        ], User::class, 'json', [
            'groups' => ['read']
        ]);
        dd($data);

Then, If I add APIResource attribute on my model, the denormalization is broken for fields with _ (here first_name)

#[ApiResource]
class User {
 // ...

How to reproduce
Add a proprerty with underscore to an entity and use the denormalizer to set the property. It will stay to null

Possible Solution
I'm currently debugging to understand what API Platform add.

[Grafikart]

After further investigation in AbstractObjectNormalizer $allowedAttributes is ["username", "firstName"] when APIResource is enabled instead of ["username", "first_name"], my guess is a problem with getAllowedAttributes() in AbstractItemNormalizer

The method $this->isAllowedAttribute($classOrObject, $propertyName, null, $context) return false and it expects a #[ApiProperty(writable: true)] attribute on the property. But I don't see ApiProperty documented a lot on the documentation so I wonder if adding the APIProperty attribute is still the way to go ?

[soyuka]

There should be some kind of NameConverter that isn't doing things right.

[Grafikart]

If it helps I created a blank project (--webapp) with symfony and added api platform with composer require api to be sure I don't have parasit code. Since the #[ApiProperty] exists there is not urgency.

[jbtronics]

This problem is related to issue #1554
API platform basically considers all snake_case style properties as readonly, and therefore ignores the data on denormalization.
This is actually caused by an issue (or an inconsistency) in the PropertyInfo symfony component API Platform uses to determine if a property is writeable.

For some reason this component considers an object with a camelCase style getter as readable (therefore reading works fine in API platform), but it completely ignores the camelCase style setters and therefore reports the property as readonly. However the setter method is accessible by the serializer and PropertyAccess component (as can be seen, when you override that info with the APIProperty attribute), and therfore the reported information is flawed.
If your setter would be named setFirst_name() in your example, the PropertyInfo correctly reports the property as writable and API Platform would behave fine.

I have submitted a pull request to the PropertyInfo component which should fix this issues.

[jbtronics]

As a workaround until the PR is merged, you can define an additional PropertyAccessExtractorInterface service for the PropertyInfo component, which can correctly handle the ability to write snake_case properties with camelCase setter.

See this gist for an example: https://gist.github.com/jbtronics/0e0f36cfaf49d13d13fa0b8023532b9b

[soyuka]

thanks @jbtronics let us now if this doesn't solve your issue