[ValeriaMaltseva]

Changes in this pull request

Resolves pimcore/platform-version#577

Opening the dropdown of a classification store select key with an options provider failed with Class with ID: 1 not found. Studio UI sent only the key id (fieldName=6). The dot notation parser had no classification store case, and the broad catch (Exception) in SelectOptionsService replaced the real parse error with a misleading "class not found".

• New ClassificationStoreResolver for <storeFieldName>.<groupId>.<keyId>. It also accepts <storeFieldName>.<groupId>.<language>.<keyId>, which the language comparison view sends; the key definition doesn't depend on the language. It looks up the KeyGroupRelation and builds the key definition from it.
• FieldDefinitionWrapper::getOptionsProviderContext() (optional, defaults to []). The resolver fills it with the context core's classification store layout enrichment passes: ownerType, ownerName, keyId, groupId, keyDefinition. SelectOptionsService merges it into the provider context, so providers get the same context on refresh as on the initial layout load.
• Error reporting: a ParseException now becomes an InvalidArgumentException (422) with the real message. Other failures keep the existing NotFoundException.

Needs the Studio UI change that sends the new field name: pimcore/studio-ui-bundle#4264

Additional info

Verified locally:

• Unit tests, all passing: the new ClassificationStoreResolverTest, 2 new cases in SelectOptionsServiceTest (the owner context reaches the provider; a parse error keeps its message), and the existing BlockResolverTest.
• PHPStan on the changed files: no errors.
• After a cache clear, the resolver is registered under the pimcore.studio_backend.field_definition_resolver tag.
• Against real demo data, read-only (AccessoryPart, technicalAttributes): technicalAttributes.3.6 and technicalAttributes.3.en.6 both resolve to the Select key rimMaterial with key 6 and group 3. A wrong group gives Key "6" does not exist in classification store group "4".

Not verified: php-cs-fixer isn't installed in the dev container, so CI is the style check. I haven't tested a real options provider in a running Studio, because the demo has no classification store key with a provider configured.

Manual test:

1. Create a classification store select key and set "Options Provider Class or Service Name" to an @service provider.
2. Add the key to a group, open an object, add the group and open the dropdown. The options load, and the provider receives ownerType=classificationstore, ownerName, keyId and groupId.
3. Repeat in the language comparison view for a localized store.
4. Spot-check a normal select field and one inside localized fields.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The shared helper breaks compatibility with existing overrides, and key resolution lacks validation against the owning field’s configured store.

2 open issues

• Preserve wrapFieldDefinition inheritance compatibility · New
• Reject key groups from a different classification store · New

What changed in this PR

Verdict: Needs changes. This PR addresses classification store dropdown failures from pimcore/platform-version#577 by resolving key paths and preserving the context expected by dynamic options providers.

Changes:

• Registers a resolver for classification store paths, including the language-comparison form.
• Carries owner context through the field-definition wrapper to options providers.
• Reports parse failures as invalid arguments and adds focused regression tests.

The fix targets the underlying parsing and context gaps at the resolver/service boundary (ClassificationStoreResolver.php:70–110, SelectOptionsService.php:76–98). The tests cover resolution, provider context, and error reporting; they were not executed during this review. Shared extension compatibility remains unresolved.

No documentation changes are included. The coordinated UI change in pimcore/studio-ui-bundle#4264 and a running-Studio check with a real provider remain integration requirements, including a maintainer check of store-boundary validation.

File	Description
tests/​Unit/​FieldDefinition/​Parser/​Resolver/​ClassificationStoreResolverTest.php	Tests key paths, owner context, and lookup failures.
tests/​Unit/​DataObject/​Service/​SelectOptionsServiceTest.php	Tests provider context and preserved parse messages.
src/​FieldDefinition/​Parser/​Resolver/​ClassificationStoreResolver.php	Resolves classification store keys and supplies owner context.
src/​FieldDefinition/​Parser/​Resolver/​AbstractResolver.php	Extends the wrapper helper to pass provider context.
src/​FieldDefinition/​FieldDefinitionWrapper.php	Stores optional options-provider context.
src/​DataObject/​Service/​SelectOptionsService.php	Passes context to providers and distinguishes parse errors.
config/​field_definition.yaml	Registers the classification store resolver.

_{Review effort: Balanced}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

🔵 Needs a closer look

The real options-provider flow and coordinated Studio UI integration still require maintainer validation in a running Studio.

No open issues 🎉

2 resolved since last review

• Preserve wrapFieldDefinition inheritance compatibility
• Reject key groups from a different classification store

_{Review effort: Balanced}