Description
✏️ Describe the bug
Function in ResolvedDataPipeline uses inputMappedName irrespective of whether the creationContext->mapPropertyNames is true or not
public function transformNormalizedToArray(
Normalized|array $normalized,
CreationContext $creationContext,
): array {
if (! $normalized instanceof Normalized) {
return $normalized;
}
$properties = [];
$dataClassToNormalize = $creationContext->dataClass !== $this->dataClass->name
? app(DataConfig::class)->getDataClass($creationContext->dataClass)
: $this->dataClass;
foreach ($dataClassToNormalize->properties as $property) {
// This will always pick up the $property->inputMappedName even if the context has the properties switched off
$name = $property->inputMappedName ?? $property->name;
$value = $normalized->getProperty($name, $property);
if ($value === UnknownProperty::create()) {
continue;
}
$properties[$name] = $value;
}
return $properties;
}
}
Potential fix
foreach ($dataClassToNormalize->properties as $property) {
$name = $creationContext->mapPropertyNames && $property->inputMappedName
? $property->inputMappedName
: $property->name;
$value = $normalized->getProperty($name, $property);
↪️ To Reproduce
Provide us a pest test like this one which shows the problem:
Sorry, not sure exactly how to reproduce the issue as I was doing a deep dive in the code with regards to how Collections work. Manually manipulated creationContext properties and the mapping was still taking place.
✅ Expected behavior
When creationContext->mapPropertyNames = false, transformNormalizedToArray will not use mappings to set the $property->name
I'm not sure exactly what upstream implications this might have, and its possible that I have misunderstood how this works in the codebase, but it was something I noticed on my travels and felt that it should be raised :)
🖥️ Versions
Laravel: v11.44.7
Laravel Data: 4.17
PHP: 8.3,