Skip to content

fix: preserve custom label colours when editing - #577

Merged
hjball merged 1 commit into
kanbn:mainfrom
habralab:fix/custom-label-colour-editing
Sep 4, 2026
Merged

fix: preserve custom label colours when editing#577
hjball merged 1 commit into
kanbn:mainfrom
habralab:fix/custom-label-colour-editing

Conversation

@bionicman

Copy link
Copy Markdown
Contributor

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,
LabelForm could not resolve a selected option and attempted to render an
undefined 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

  • Bug fix
  • Feature (requires an approved issue — see below)
  • Refactor / chore
  • Documentation

Checklist

  • I have linked the related issue below
  • My code follows the existing style and conventions
  • I have tested my changes locally
  • I have included screenshots for any UI changes

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 passed
  • targeted ESLint and Prettier checks for the changed files
  • pnpm --filter @kan/e2e typecheck
  • self-hosted card-labels.spec.ts against PostgreSQL 16 — 1 test passed
  • Next.js production build completed as part of the Playwright run

Linked issue

Not applicable: this fixes editing for custom label colours already accepted by
the API, database and MCP.

@bionicman

bionicman commented Sep 4, 2026

Copy link
Copy Markdown
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.

@hjball hjball 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.

lgtm @bionicman

@hjball
hjball merged commit 8aee964 into kanbn:main Sep 4, 2026
2 checks passed
kevinm6 added a commit to kevinm6/kan that referenced this pull request Sep 4, 2026
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.

2 participants