Color Picker: Refresh stored label when data type label changes (closes #22741)

[AndyButland]

Description

When the label of a colour in a Color Picker data type is changed, content already using that colour does not pick up the new label on the next publish. Looking at the stored property data, I can see the old label is still stored. This explains why the delivery API serves the out of data value.

Looking at the linked issue history, it seems the previous (AngularJS) editor handled this in Umbraco 13; but the new one does not.

Root cause: the property data is a compound object { value, label }. The property editor UI receives value (saved data with the old label) and config (current swatches with the new label) on independent setters, but never reconciles them. Without user interaction with the swatch, no change event fires and the stale label is re-persisted.

Fix: in property-editor-ui-color-picker.element.ts, after either setter runs, look up the matching swatch by hex value. If the swatch's label differs from the stored value's label, replace the value and dispatch UmbChangeEvent so the corrected label is persisted on the next save.

Fixes #22741

Testing

• Create a Color Picker data type with two colours: labels "first" and "second".
• Create a doc type with the data type and a content node, select the "first" colour, save & publish.
• Edit the data type and change the "first" label to "third", save.
• Open the same content node and click "Save and publish" without touching the swatch.
• Query the database using select top 100 * from umbracoPropertyData order by id desc. Look at the varcharValue field that will contain a value like: { "label": "third", "value": "#514c94" }. Before this PR it would have { "label": "first", "value": "#514c94" }
• Verify fresh selections still save correctly.

[claude]

Claude finished @AndyButland's task in 3m 17s —— View job

---

PR Review

Target: origin/main · Based on commit: b3f1ca53ae34ad35670a8019ff8d0b59ee37aee5

Fixes a regression in the Lit-based Color Picker editor where a changed data-type swatch label was never reconciled with the stored { value, label } compound object, causing the Delivery API to return the stale label. The fix adds #syncLabelFromSwatches(), called from both the value and config setters, which detects a label mismatch and emits UmbChangeEvent so the corrected label is persisted on the next save.

• Other changes: When a content item is opened and its stored color label is out of date (the data type label was changed since last save), the workspace will now be marked dirty immediately on open — before the editor touches anything. This is intentional: it ensures the corrected label is persisted on the next explicit save. Editors will see an "unsaved changes" indicator the moment they open such a node.

---

Important

• property-editor-ui-color-picker.element.ts:56–63 (inline comment posted): No automated test for the label-sync logic. Both setter orders (config-before-value, value-before-config) and the no-mismatch case (event must NOT fire when labels already match) should be covered. See inline comment for a concrete test structure.

Suggestions

• property-editor-ui-color-picker.element.ts:61: The immediate-dirty side-effect noted above is observable but not guarded by a comment. Consider adding a brief inline note on the dispatchEvent call (e.g., // intentional: ensures stale label is persisted on next save) so future maintainers understand why the event fires outside of user interaction.

---

Approved with Suggestions for improvement

The fix is correct and tightly scoped — the guard (!this.value || this._swatches.length === 0) prevents spurious events, super.value = match correctly bypasses the setter to avoid recursion (swatches in _swatches are already hash-prefixed), and the behavioral change mirrors the previous AngularJS editor. Please add test coverage before merging.

Labels applied: area/frontend, category/ux

[Copilot]

Pull request overview

This PR fixes stale Color Picker labels being re-persisted (and thus returned by the Delivery API) when a data type swatch label changes but the selected color value does not, by reconciling the stored { value, label } against the current swatch configuration and emitting a change event to persist the updated label.

Changes:

• Sync stored value.label from the configured swatches whenever either value or config is set.
• Dispatch UmbChangeEvent when a label mismatch is detected so the corrected label is persisted on next save/publish.

[iOvergaard]

Picked for 17.4 through 17e73ee

[iOvergaard]

Picked for 18.0 through dc446c0