fix(object-mapper): on creation, give expected class to object mapper

[Cafeine42]

Q	A
Branch?	4.2
License	MIT

When the input DTO or the API resource has multiple mapping targets, during a POST request with ApiPlatform, provide the expected target to the objectMapper to ensure the correct mapping is used.

[soyuka]

28834e6 should fix some of the input/output issues can you check if you're using the 4.3 version?

[Cafeine42]

Same error, but on vendor/api-platform/core/src/State/Processor/ObjectMapperInputProcessor.php:54

My ObjectMapper implementation does not tolerate a null target in order to preserve my developers’ sanity. However, it remains a valid use case in scenarios involving multiple mappings.

I haven’t reviewed the entirety of 4.3, but is it planned to allow calling the security layer after the ObjectMapperInputProcessor is executed? I have a use case where my voters require the entities to validate security, since I need properties that are not exposed in the ApiResource or the DTO.

Regarding validation, has anything been planned to allow validating both the input (DTO or ApiResource) and the entity? It is possible to implement custom validators to access the entity, but validating the entity after mapping remains more practical and avoids having to retrieve data from Doctrine.

[soyuka]

I haven’t reviewed the entirety of 4.3, but is it planned to allow calling the security layer after the ObjectMapperInputProcessor is executed? I have a use case where my voters require the entities to validate security, since I need properties that are not exposed in the ApiResource or the DTO.

Interesting use case we may need a new security layer in there. Could you provide a functional test case?

Regarding validation, has anything been planned to allow validating both the input (DTO or ApiResource) and the entity? It is possible to implement custom validators to access the entity, but validating the entity after mapping remains more practical and avoids having to retrieve data from Doctrine.

IIRC a recent patch has been merged for this as there was a bug with the UniqueEntity constraint. Let me know if you struggle with that.

[Cafeine42]

I made the PR for 4.3 #7796 with the minimal change in tests.

Regarding validation, has anything been planned to allow validating both the input (DTO or ApiResource) and the entity? It is possible to implement custom validators to access the entity, but validating the entity after mapping remains more practical and avoids having to retrieve data from Doctrine.

IIRC a recent patch has been merged for this as there was a bug with the UniqueEntity constraint. Let me know if you struggle with that.

I just tested with the main branch and it works fine for my project.

From what I understand, the validator runs first on the DTO / ApiResource, then on the mapped object. So validation happens at both levels.

Since it runs in two sequential steps, a validation error on the mapped object won’t be returned if a validation error already occurred on the input DTO. The calls are executed one after the other.

In the future, there might be a need to collect and return all validation errors so we can surface issues from both the DTO and the mapped object. That said, the current behavior works perfectly fine for my project.

I haven’t reviewed the entirety of 4.3, but is it planned to allow calling the security layer after the ObjectMapperInputProcessor is executed? I have a use case where my voters require the entities to validate security, since I need properties that are not exposed in the ApiResource or the DTO.

Interesting use case we may need a new security layer in there. Could you provide a functional test case?

I’m starting to work on this topic.

[Cafeine42]

Quick thought: on a POST operation, if the mapped_object could be initialized via the api_platform.state_provider.locator alias, my fix would no longer be necessary. It would also likely make the mapped_object available during the security evaluation on a POST. Irrelevant

[Cafeine42]

I initially tried applying the project's legacy voters, but after reviewing it, that approach doesn’t make sense in this specific case.
In my use case, validating that a user has permissions on an object they just created is redundant, as this is already enforced through validator.
The security is OK on PUT/PATCH in my project.

So this part is fine for me, just need the target class on map call.