fix: preserve custom label colours when editing - #577
Merged
Conversation
Contributor
Author
|
A little context for why this general fix came up: I have a follow-up ready for the Trello importer. It preserves Trello's label colours instead of assigning Kan colours by array position, and explicitly requests because Trello otherwise limits nested labels to 50. That importer can create HEX values outside Kan's built-in editing palette, so this PR is the small general prerequisite: imported labels should remain editable without losing their stored colour. I'll open and link the importer change as a separate PR after this lands, so the scope here stays focused. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Labels created through the API or MCP can use a colour outside the built-in
eight-colour palette. When one of those labels was opened for editing,
LabelFormcould not resolve a selected option and attempted to render anundefined value.
This keeps the existing creation palette unchanged while treating the stored
HEX value as the current option when it is not one of the presets. The label can
then be opened and saved without losing its colour, or changed to one of the
normal presets.
The shared resolver is covered for preset, custom and missing colour values.
The existing self-hosted label scenario now also assigns a custom colour via
the API, opens the edit form and saves it again.
Type of change
Checklist
There is no intended layout or design change; this restores the edit form for
an already supported stored value.
Testing
pnpm --filter @kan/web test— 11 tests passedpnpm --filter @kan/e2e typecheckcard-labels.spec.tsagainst PostgreSQL 16 — 1 test passedLinked issue
Not applicable: this fixes editing for custom label colours already accepted by
the API, database and MCP.