8000 Add board-level custom fields · Issue #594 · kanbn/kan · GitHub
[go: up one dir, main page]

Skip to content

Add board-level custom fields #594

Open

Description

@bionicman

Title: Add board-level custom fields

✨ Feature Request

Is your feature request related to a problem? Please describe.

Cards often need a small amount of structured metadata that does not fit labels,
members or due dates: a workflow status, customer or ticket reference, story
points, a review date, or a yes/no flag. Labels can approximate some of these,
but they cannot keep the field name, value type and meaning separate.

This also matters for migration. We are moving a sizeable workspace from Trello,
where 14 boards currently use 36 custom-field definitions and 4,585 populated
values. Dropping them or flattening them into card descriptions would make the
cards harder to filter and maintain after the move.

Describe the solution you'd like

  • Custom-field definitions belong to a board and support text, number,
    date/time, checkbox and single-select values.
  • Board editors can create, rename, reorder and archive fields, choose whether a
    value is shown on the card front, and manage ordered, coloured select options.
  • Card editors can set or clear values from the existing card side panel.
  • Populated fields marked for the card front appear as compact named values on
    board cards.
  • Board filters keep definitions under one top-level Custom fields group,
    then expose each field and its applicable controls. They support select and
    checkbox values as well as text contains, number equals/range and date
    before/after/range.
  • Card duplication, board templates and cross-board moves preserve values rather
    than silently dropping them.
  • The existing Trello importer can bring across current definitions, options and
    values.

There is no separate enable switch. The first field activates the UI for that
board; a board without fields stays unchanged. The existing board:edit and
card:edit permissions also seem sufficient, without adding a new RBAC area.

Describe alternatives you've considered

Using labels for every structured value mixes unrelated namespaces and does not
cover text, number or date values. Putting key/value lines in descriptions keeps
the text visible but loses validation, filtering and safe updates. A generic
plugin or formula system would be much larger than the immediate need and can be
built on top later if that direction makes sense.

Additional context

We are already trying this in our fork because preserving this workflow is part
of our Trello migration. The implementation is deliberately provider-neutral;
the Trello adapter is only one import path.

The overall field model is informed by Trello's custom fields. We have found
that model well considered in everyday use, and keeping its familiar concepts
makes migration easier without making the feature Trello-specific. It also
provides a useful foundation for small board automations. We are already
exploring how to migrate the automations our teams rely on into our fork,
although automation itself is outside the scope of this proposal.

Board cards with field values:

Custom fields on board cards

Editing populated values for all supported field types on a card:

Custom field editors

Field management, filtering and mobile

Board custom-field management

Dropdown custom-field options

Custom fields in the board filter menu

Filtering by a select field

Empty custom-field manager

Main-panel custom fields on mobile

Sidebar custom fields in the mobile card drawer

Custom-field management on mobile

The implementation is ready for review in #609 and remains available in the
feat/custom-fields
branch of my fork. It is rebased on the current upstream main and validated
locally. I am happy to adjust the product boundaries or split the implementation
if the maintainers prefer a different shape.

Related work

After opening this issue I found #534, which explores a broader schema-driven
board customisation system: YAML configuration, custom sections, placement in
the main panel or sidebar, built-in field overrides and several composite field
types. There is useful product work there, but its goal and persistence model
are different from this proposal. This issue focuses first on Trello-compatible
typed fields with stable definitions and options, filtering, lifecycle rules
and import support. The broader form-building ideas could be layered on top
rather than making YAML and a per-card JSON document the identity model for the
first version.

Implemented follow-ups in the current branch

  • Show and populate custom fields while creating a card, with optional field
    descriptions, placeholders and server-applied default values.
  • Add simple field sections and choose whether a field belongs in the main card
    panel or sidebar. This would remain a flat, managed layout rather than an
    arbitrary recursive form schema.

Possible follow-ups

  • Consider multi-select and searchable/autocomplete fields after the initial
    value and filtering model has settled.
  • Explore a member-valued field for roles such as supervisor or executor. Trello
    does not have this field type, and it needs separate product decisions around
    paused members, historical attribution and cross-workspace moves.

After #581 landed, the current branch reuses its nested navigation and selected
counts. Field definitions now sit below one top-level Custom fields entry
rather than adding every field to the first menu level. The screenshots above
have been refreshed.

Implementation ideas (optional)

The implementation uses board-owned definitions and options plus one typed value
row per card and field. Database constraints enforce the value shape and field
ownership. Definitions are projected once per board, while compact card values
carry IDs and typed values only. Filtering resolves each typed condition to a
compact matching-card set with selective indexed queries rather than per-card
lookups.

Field and option archival preserves existing values. Cross-board moves keep an
explicit source-to-target mapping so equal display names do not become identity,
and ambiguous matches fail rather than choosing silently. Current custom fields
from Trello are imported through the stock adapter with synthetic coverage; our
larger migration tooling remains separate from the proposed product feature.

The implementation has repository, API, web and import coverage, including
permissions, typed constraints, lifecycle races, card and board duplication,
cross-board mapping, filters, mobile interactions and Trello import shapes. It
has also been exercised with a production-shaped board containing 1,199 cards
with custom-field values and 2,279 value rows.

Would you like to work on this feature?

  • Yes, I'd like to help implement this feature
  • No, I'm just suggesting the feature

Activity

  1. hjball commented on Sep 7, 2026

    @hjball
    Contributor

    This is desperately needed @bionicman

    I think starting with the custom fields Trello supports make sense, but we should try to keep the scope of this as limited as possible for the first release.

    We may need to tweak the UI/UX once merged but I'm happy for you to take a first pass at it. The most import things is that we have the structure in place and it's extensible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    0