Skip to content

[Studio] Fix blank unit selection for the static Quantity Value transformer - #683

Open
ValeriaMaltseva wants to merge 3 commits into
2026.xfrom
fix/quantity-value-transformer-unit-list-2026.x
Open

[Studio] Fix blank unit selection for the static Quantity Value transformer#683
ValeriaMaltseva wants to merge 3 commits into
2026.xfrom
fix/quantity-value-transformer-unit-list-2026.x

Conversation

@ValeriaMaltseva

Copy link
Copy Markdown

Problem

The unit select of the Quantity Value transformer is always empty when Unit source is set to
Static.

Fixes pimcore/platform-version#148 on 2026.x.

Root cause

UnitDataResponse documented its list under the OpenAPI property name UnitList, while the
serializer emits the actual property name — unitList:

{"unitList":[{"unitId":"kg","abbreviation":"kg"}],"additionalAttributes":[]}

The generated API client therefore typed the response as UnitList, and
quantity-value-transformer-form.tsx read unitData?.UnitList, which was always undefined
empty option list → blank select.

The schema annotation was already corrected to unitList in 307aeb9, but the committed OpenAPI
snapshot and the generated client on 2026.x still carry the old name — so the type checker agrees
with the broken access and never flags it.

Change

Two commits, cherry-picked from #682 so both lines carry byte-identical content:

  1. The fix
    • assets/studio/build/api/docs.jsonopenapi.json — snapshot property UnitListunitList
    • data-importer-api-slice.gen.ts — regenerated via npm run build-api-client
    • quantity-value-transformer-form.tsx — reads unitData?.unitList
    • tests/unit/UnitDataResponseTest.php — regression test: the documented OpenAPI property name
      must match the key the serializer actually emits
  2. Snapshot property metadata refresh — the committed snapshot predated several #[Property]
    annotations, so the client carried no descriptions for currentConfig.label and
    userPermissions.update/delete, and typed dataPreview.data as any.

Only the seven BundleDataImporter* schemas are touched. The snapshot keeps its existing 403 paths,
369 components and info.version: 0.13.20 — verified by structural comparison, changed paths: [].

CalculateTransformationResultTypeParameters::$currentConfig documents dataSourceIndex items as
integer, which contradicts both the frontend (dataSourceIndex?: string[] in types.ts and
throughout the advanced mapping modal) and the bundle's own ColumnHeadersResponse, where id and
dataIndex are string. That one property is deliberately left un-refreshed so dataSourceIndex
stays any until the annotation itself is corrected.

Verification

  • npm run check-types — 7 errors on this branch, the same 7 as on origin/2026.x
    (colorFillAdditional / colorFillActive missing on FullToken, in *.styles.tsx files this PR
    does not touch). No new errors.
  • npm run lint — the same 7 pre-existing no-unsafe-argument errors in those same style files.
    Nothing in the four changed files.
  • Negative test: with the snapshot and client fixed but quantity-value-transformer-form.tsx left
    reading UnitList, check-types fails exactly at the bug site —
    Property 'UnitList' does not exist on type 'BundleDataImporterUnitDataResponse'. Did you mean 'unitList'?
    So the type checker now guards this.
  • The Codeception suite was not run locally (vendor/ is not installed in this workspace; it
    needs the Docker test env + product-registration credentials) — CI validates it.
  • No frontend build artifact is committed; the "Studio Frontend Build" workflow regenerates it.

Manual test

Data Importer config → mapping to a Quantity Value field → add the Quantity Value transformer →
set Unit source to Static → the Unit select lists all quantity-value units and is searchable.

Note for consumers

Anyone who worked around this by renaming unitList back to UnitList in the response (see the
issue comment) must drop that workaround.

Relationship to #682

#682 carries the identical change against 2026.2 and is still open. This PR lands it directly on
2026.x as requested. Because the two branches were byte-identical in all affected paths and this is
a clean cherry-pick, the later 2026.2 → 2026.x forward merge resolves to the same content — if it
conflicts at all, either side is correct.

ValeriaMaltseva and others added 2 commits August 25, 2026 11:55
…former

The unit select of the Quantity Value transformer was always empty when the
unit source was set to "Static".

`UnitDataResponse` documented its list under the OpenAPI property name
`UnitList`, while the serializer emits the actual property name `unitList`.
The generated API client therefore typed the response as `UnitList` and the
transformer form read `unitData?.UnitList`, which was always undefined.

The schema annotation was already corrected to `unitList`, but the committed
OpenAPI snapshot and the generated client still carried the old name, so the
type checker agreed with the broken access. Refresh the snapshot property,
regenerate the client and read `unitList` in the transformer form.

Consumers that worked around this by renaming `unitList` back to `UnitList`
in the response must drop that workaround.

Fixes pimcore/platform-version#148

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The committed OpenAPI snapshot predated several `#[Property]` annotations in
the bundle's schema classes. The generated API client therefore carried no
descriptions for `currentConfig.label` and `userPermissions.update`/`delete`,
and typed `dataPreview.data` as `any`.

Refresh only the `BundleDataImporter*` schemas in the snapshot — 21 additions,
all property descriptions and examples plus the `dataPreview.data` string type
— and regenerate the client. Nothing outside the data-importer schemas is
touched, so the snapshot keeps its existing 403 paths and 369 components.

`CalculateTransformationResultTypeParameters::$currentConfig` documents
`dataSourceIndex` items as `integer`, which contradicts both the frontend
(string column identifiers throughout) and the bundle's own
`ColumnHeadersResponse`, where `id` and `dataIndex` are `string`. That one
property is deliberately left un-refreshed so `dataSourceIndex` stays `any`
until the annotation itself is corrected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot AI balanced review requested due to automatic review settings August 25, 2026 09:58
@sonarqubecloud

Copy link
Copy Markdown

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Verdict: Needs changes. The unitList fix addresses the root cause at the schema, generated-client, and UI boundaries, and the only frontend caller is updated.

Changes:

  • Aligns the OpenAPI snapshot and generated client with serialized unitList.
  • Updates the Quantity Value transformer to consume unitList.
  • Adds regression tests and refreshes schema metadata.

The upgrade guide already documents the rename. However, the regression test does not validate the stale generated artifacts, and dataPreview.data is incorrectly narrowed to string.

Reviewed changes

Copilot reviewed 11 out of 32 changed files in this pull request and generated 3 comments.

File Description
assets/studio/build/api/docs.jsonopenapi.json Refreshes Data Importer OpenAPI schemas.
assets/studio/js/src/modules/data-importer/data-importer-api-slice.gen.ts Regenerates client types, including unitList.
assets/studio/js/src/modules/data-importer/dynamic-types/transformer/quantity-value/quantity-value-transformer-form.tsx Reads units from unitData.unitList.
tests/unit/UnitDataResponseTest.php Adds DTO serialization/schema checks.

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

* property name has to be the one the serializer actually emits. When the two drifted apart,
* the quantity value transformer's unit select silently rendered empty.
*/
public function testDocumentedPropertyNameMatchesTheSerializedKey(): void
label?: string;
/** Cell data value */
data?: any;
data?: string;
@@ -0,0 +1,57 @@
<?php declare(strict_types=1);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DataHub Transformation Pipeline for Static Quantity Value always blank

3 participants