[ValeriaMaltseva]

Changes in this pull request

Resolves pimcore/platform-version#577

Classification store keys were rendered as ObjectComponent name={ item.id } with no CombinedFieldNameProvider, so their combinedFieldName was just the key id (e.g. "6"). DynamicSelectField sends that as fieldName to the select options endpoint. The backend couldn't resolve it, so opening the dropdown of a select key with an options provider failed.

• ClassificationStoreItem wraps the group's keys in a CombinedFieldNameProvider with [storeFieldName, groupId], so a key is now addressed as attributes.2.6.
• The store field name is passed down from ClassificationStoreContent. Both values come from a small new helper, utils/combined-field-name.ts.
• ClassificationStoreItem isn't exported from the SDK, so its new required prop doesn't affect bundles.

Needs the backend resolver for this field name: pimcore/studio-backend-bundle#2153. Both PRs have to be merged together.

Additional info

Verified locally:

• New combined-field-name.test.ts; it passes along with the other classification store util tests (16 tests).
• ESLint on the changed files.
• tsc --noEmit: no errors.

Not verified: the provider wiring has no component test, because rendering in jest is blocked by the @sdk/components → antd ESM import. Not exercised in a running Studio.

Manual test:

1. Set up a classification store select key with an @service options provider and add its group to an object.
2. Open the dropdown: the request sends fieldName=<store>.<groupId>.<keyId> and the options load.
3. In the language comparison view, check the same key in a localized store.
4. Spot-check a normal select field and a select field inside localized fields.

🤖 Generated with Claude Code

[Copilot]

🔵 Needs a closer look

The request-format change depends on an unmerged backend resolver, and provider-to-request integration remains unverified.

No open issues 🎉

What changed in this PR

Verdict: Request review. This PR addresses classification-store select-option failures by identifying keys as <store>.<groupId>.<keyId> rather than by key ID alone.

Changes:

• Extracts the store name and constructs the parent field path through shared helpers.
• Passes the store name into group rendering and wraps keys in CombinedFieldNameProvider.
• Adds unit tests for store-name extraction and key-path construction.

Assessment:

• Root cause and boundary: The provider supplies the missing context at the owning classification-store component (classification-store-item.tsx:130–140), addressing field identification rather than masking the request failure.
• Call sites and compatibility: The supplied caller passes the new required prop (classification-store-content.tsx:173). Coverage of all callers and the stated absence of SDK exposure are not independently established here. The request format requires coordinated delivery with backend PR #2153, which remains open.
• Tests and remaining risk: Helper tests cover path construction (combined-field-name.test.ts:13–32), but not provider-to-request integration. Running-Studio validation remains outstanding.
• Documentation: The PR description explains the format and deployment dependency; no documentation or changelog file is changed.

File	Description
assets/​js/​src/​core/​modules/​element/​dynamic-types/​definitions/​objects/​data-related/​components/​classification-store/​utils/​combined-field-name.ts	Adds store-name and group-path helpers.
assets/​js/​src/​core/​modules/​element/​dynamic-types/​definitions/​objects/​data-related/​components/​classification-store/​utils/​combined-field-name.test.ts	Tests name extraction and qualified key paths.
assets/​js/​src/​core/​modules/​element/​dynamic-types/​definitions/​objects/​data-related/​components/​classification-store/​classification-store-item.tsx	Provides store and group context to rendered keys.
assets/​js/​src/​core/​modules/​element/​dynamic-types/​definitions/​objects/​data-related/​components/​classification-store/​classification-store-content.tsx	Passes the store field name to each group.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

An unresolved finding flags Array.isArray in combined-field-name.ts as inconsistent with the repository’s convention of using lodash’s isArray.

1 open issue

• Use lodash isArray for consistent type checking · New

_{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 field-name contract depends on studio-backend-bundle#2153, while provider-to-request wiring lacks component or running-Studio validation, requiring coordinated verification of both bundles, including language comparison.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Use lodash isArray for the type guard

assets/​js/​src/​core/​modules/​element/​dynamic-types/​definitions/​objects/​data-related/​components/​classification-store/​utils/​combined-field-name.ts:15

Please use lodash's isArray here to match the explicit type-guard convention in .github/copilot-instructions.md:231–236. The surrounding classification-store components already use that guard.

1 resolved since last review

• Use lodash isArray for consistent type checking

_{Review effort: Balanced}