PROD-2431/2435/2442: remap Linked Content selections (checkbox/dropdown/grid) during sync

[5PK]

Summary

Fixes PROD-2431, PROD-2435, and PROD-2442 — three related bugs where ContentFieldMapper fails to remap a Linked Content field's actual selection during cross-instance sync, each shipping raw SOURCE-instance content IDs into the target. Same root class of bug in three different field shapes: a checkbox/multi-select field's companion value column, an arbitrarily-named dropdown companion column, and a full-list grid field's own sort order.

PROD-2431 — checkbox/multi-select companion field not remapped

Checkbox/multi-select Linked Content fields store the actual selection as a comma-separated content-ID string in a sibling <field>_ValueField field. The main field's own sortids was already being remapped correctly, but the sibling _ValueField is a bare string, not an object — isContentReferenceField() only recognizes object-shaped values — so it fell through unmapped and shipped raw SOURCE content IDs into the target on every sync. Symptoms: field appears empty with no container bound, or shows the source instance's raw content IDs as orphaned "checked" items.

PROD-2435 — companion field has no fixed naming convention

The _ValueField suffix heuristic from the PROD-2431 fix doesn't hold generally: sampling the target schema, only 4 of 14 dropdown fields actually use that suffix (e.g. PlayslipSection names its companion linkedContentId, HotAndColdNumbersSection uses LinkedContentValue). The real, authoritative name is the field's own model setting, settings.LinkeContentDropdownValueField — mapContentFields() now reads that directly off a model field added to ContentFieldMappingContext, instead of guessing a suffix. Matches case-insensitively (schema casing vs. payload key casing can differ) and tolerates a self-pointing setting or a sentinel value (e.g. "CREATENEW") that names no real field.

PROD-2442 — full-list grid field's own sortids never reached the remap

While live-testing every Linked Content render style (dropdown/checkbox/searchlistbox/shared grid/shared link/nested) against the PROD-2431/2435 fix on a throwaway test instance, found a third, more severe gap: mapSingleField() checks isListReferenceField() (referencename + fulllist:true) before isContentReferenceField(), and returns the field unchanged immediately on a match. A full-list "grid" Linked Content field matches that shape too — but can also carry a populated sortids (a custom sort order, via the model's SortIDFieldName setting, the grid analogue of LinkeContentDropdownValueField). That sortids — the field's own primary value, not just a companion — never reached the remap logic at all, and its SortIDFieldName companion column had the same "no fixed naming convention" problem as PROD-2435, uncovered by that fix since it only reads LinkeContentDropdownValueField.

Verified this against the real server code the CLI's Sync SDK reads from (ContentRepoItemBuilder.cs / classic ContentRepoManagement-GetContentRepoItem.cs) and confirmed live by executing the mapper against a real reproduction:

sharedGridSorted.sortids AFTER mapping: 13088,13087,13086,13085,13084   ← should be 14088,14087,14086,14085,14084
sharedGridSorted_SortField AFTER mapping: 13088,13087,13086,13085,13084 ← should be 14088,14087,14086,14085,14084

Fix

In src/lib/content/content-field-mapper.ts:

• mapContentFields() walks fields a second time after the main pass: for any field whose model setting names a companion column (LinkeContentDropdownValueField or, as of PROD-2442, SortIDFieldName), remap its comma-separated ID string through the same content-item reference mapper used for sortids. Shared split/map/join logic lives in mapContentIdListString().
• isListReferenceField() now also requires an empty/absent sortids — a populated one falls through to the existing mapContentReferenceField() remap path instead of short-circuiting as an inert list-by-name reference.
• getContentDropdownValueFieldNames() falls back to SortIDFieldName when LinkeContentDropdownValueField isn't set, so a grid field's own companion column is covered by the same mechanism.

Testing

• src/lib/content/tests/content-field-mapper.test.ts: covers the _ValueField companion remap alongside sortids, an arbitrarily-named/case-mismatched companion, self-pointing and sentinel settings, no-op/back-compat cases, a grid field's sortids now getting remapped instead of short-circuiting (with a no-regression case for the common blank-sortids grid field), and the SortIDFieldName companion remap.
• Full suite: npm test — 105 suites / 1914 tests passing, no regressions.
• npm run build — compiles clean.

🤖 Generated with Claude Code

[5PK]

Update: generalized the fix to also cover PROD-2435

The original commit fixed _ValueField-suffix-named companion fields (PROD-2431's LoyaltyLevelsTable case). Investigating the linked ticket PROD-2435 found the companion field has no fixed naming convention — PlayslipSection/WinningNumbersSection name theirs linkedContentId, HotAndColdNumbersSection uses LinkedContentValue. A sweep of the target instance's schema confirmed only 4 of 14 dropdown fields actually use the _ValueField suffix; the rest are arbitrarily named.

This commit replaces the suffix heuristic with a schema-driven lookup: each Content-typed field's model settings already record LinkeContentDropdownValueField (Agility's own spelling), naming its real companion field. mapContentFields() now reads that directly via a new model field on ContentFieldMappingContext, and content-batch-processor.ts passes the already in-scope sourceModel through at the one call site.

This is a strict superset of the original fix — it covers PROD-2431's case too, just via the schema instead of a suffix guess — and additionally resolves PROD-2435's LinkedContentDropdown companion-field bug across PlayslipSection, WinningNumbersSection, and HotAndColdNumbersSection.

Handles two edge cases found in the schema sweep:

• Self-pointing settings (e.g. GameBanner's field names itself as its own companion) — skipped to avoid double-processing.
• Sentinel values that aren't real field names (e.g. PostsListing's setting is the literal string "CREATENEW") — tolerated as a lookup miss rather than throwing.

Testing: replaced the 4 old suffix-only tests with 8 covering both tickets' cases, the two edge cases above, case-insensitive field-name matching, and back-compat (no model / no matching setting in context). Full suite: 105 suites / 1911 tests passing. Build clean.

Note: this is a forward-fix — it prevents the bug on future syncs but doesn't retroactively repair content items already corrupted on affected target instances; those still need a re-sync/re-push after this ships.

🤖 Generated with Claude Code