getCustomLayoutDefinitionForGridColumnConfig() mutates the supplied class definition #497

Activity

1. movingthings

   added the

   Bug

   issue type on Sep 16, 2026
2. github-actions

   updated Affected capability Data Objects and Platform Version 2025.4 - LTS on Sep 16, 2026
3. astapc

   added

   Pimcore:ToDo

   on Sep 17, 2026
4. astapc

   added this to the 2026.4 milestone on Sep 17, 2026
5. aKugler commented on Oct 2, 2026

   

   aKugler

   on Oct 2, 2026

   More actions

   Hi!
   Additional findings from our setup (Pimcore 2026.2.12 / Studio Backend 2026.2.10) that go beyond the object-brick case:

   1. It is not limited to restricted contexts. Any non-admin user triggers it, and fields inside a Block are always removed.
   For a non-admin user and an existing object, getCustomGridFieldDefinitions() returns the class's top-level field definitions (the caller adds the localized fields), also when no custom layout is assigned. doFilterCustomGridFieldDefinitions() recurses into nested containers and removes every child that is not in that map. Fields inside a Block are never top-level, so they are always removed, even when nothing should be excluded.

   2. The deep-copy workaround stops the mutation, but the result is still wrong for Blocks.
   With Service::cloneDefinition($class) passed in, the supplied class definition keeps its Block children. The returned layoutDefinition still contains the Block without any fields (getFieldDefinitions() returns []). So the filter itself needs to handle fields nested in a Block, not only work on a copy.

   Reproduction (class with a Block field packaging containing packedValue and packagingUnitId, a non-admin user without custom layouts, any existing object ID):

   $class = ClassDefinition::getByName('Product');
   $block = $class->getFieldDefinition('packaging');
   var_dump((bool) $block->getFieldDefinition('packedValue')); // true
   
   DataObject\Service::getCustomLayoutDefinitionForGridColumnConfig($class, $anyObjectId, $nonAdminUser);
   
   $block = ClassDefinition::getByName('Product')->getFieldDefinition('packaging'); // same instance
   var_dump((bool) $block->getFieldDefinition('packedValue')); // false
   var_dump(array_keys($block->getFieldDefinitions()));      // []

   3. Consequences of the mutation for Block data. These last until the runtime cache is cleared (end of the request, or the next message in a messenger worker). Reproduced locally:

   • Loading an object logs class definition seems to have changed, element name: … for every Block child (Block::getDataFromResource()), and the Block items come back empty.
   • For Block data that was already loaded before the mutation, the lookup $fieldDefinitions[$key] that generic-data-index-bundle's BlockAdapter::normalize() performs without a check raises Undefined array key "packedValue".
   • Block::getDataForResource() serializes such data as a:1:{i:0;a:0:{}} instead of the two fields, because it skips elements without a field definition. A save in that state would therefore write empty Block items. We have not run an actual save.

   4. Exports by non-admin users trigger it.
   The data-object ExportDataCollectionHandler calls ColumnConfigurationService::getAvailableDataObjectColumnConfiguration($classId, 1, $user) before it loads the objects to export. That path goes through the grid column collectors (FieldDefinitionCollector, AdvancedColumnCollector, ObjectBrickCollector) and Grid\Service\ClassDefinitionService into this method. In production we get the BlockAdapter error with a stack trace through exactly this handler (ExportDataCollectionHandler → GridService::getGridValuesForElement() → getGridDataForElement() → … → BlockAdapter::normalize()).