feat(kanban): user-defined custom fields on cards#39
Conversation
Let a board declare custom fields (key/label/type) that render as editable inputs on each card. File-board values live in card frontmatter (so they ride document sync to desktop + web); DB-board values live in properties_extra (cloud-only). - shared/lib/board.ts: BoardFieldDef + config.fields + card.custom + pickCustomFields() helper. - jtype-core: scan_board_cards now returns the full frontmatter map (properties) so the desktop can surface declared custom fields without re-reading files. - BoardPeek: render a typed input (text/number/date) per declared field, plus an inline "+ Add field" composer. - BoardSurface: pass fields + wire onAddField → setConfig (slug-keyed, deduped). - Desktop + web file-board adapters: read declared keys from frontmatter into card.custom and write them back on updateCard. DB board: read/write properties_extra (merged with the existing icon handling). - Thread `fields` through all three platform config types. - tests/unit/boardCustomFields.spec.ts + i18n (zh). Verified: cargo check + 34 jtype-core tests, root+web tsc, TS unit tests, and a throwaway harness confirmed typed field inputs populated from card data and the add-field composer appending a new field live. Follow-up: select-type fields with options, delete/rename field defs, showing custom fields on the card face. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 1 minute and 43 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (17)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…iew #39) onAddField slugified the label and only de-duped against existing field keys, so a field named "Status"/"Due"/"Board"/… produced key status/due/board and writing its value would clobber the card's core frontmatter. Seed the dedup set with RESERVED_CARD_KEYS (title/board/status/position/priority/assignee/due/tags/icon/ blocked_by/blocks/relates/attachments) so a colliding label is disambiguated (e.g. status -> status-2). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…-fields # Conflicts: # services/jtype-core/src/lib.rs # services/jtype-web/frontend/src/pages/Kanban.tsx # services/jtype-web/frontend/src/pages/WebBoardView.tsx # shared/components/board/BoardPeek.tsx # shared/components/board/BoardSurface.tsx # shared/i18n/locales/en/messages.mjs # shared/i18n/locales/ja/messages.mjs # shared/i18n/locales/ko/messages.mjs # shared/i18n/locales/zh/messages.mjs # shared/lib/board.ts # src/components/BoardView.tsx # src/lib/types.ts
1 participant
What
Implements C5 — boards can declare custom fields (key / label / type) that render as editable inputs on each card.
Following the data-location rule: file-board values live in card frontmatter (so they ride document sync to desktop + web); DB-board values live in
properties_extra(cloud-only).Changes
shared/lib/board.ts—BoardFieldDef+config.fields+card.custom+pickCustomFields().jtype-core—scan_board_cardsnow returns the full frontmatter map (properties), so the desktop can surface declared custom fields without re-reading files.BoardPeek— a typed input (text / number / date) per declared field, plus an inline "+ Add field" composer.BoardSurface— passesfieldsand wiresonAddField → setConfig(slug-keyed, de-duplicated).card.customand write them back onupdateCard. The DB board reads/writesproperties_extra(merged with the existing icon handling).fieldsthreaded through all three platform config types.tests/unit/boardCustomFields.spec.ts+ i18n (zh).Verification
cargo check+ 34jtype-coretests pass; root + webtscclean; TS unit tests pass.Story Points=5 number,Owner Team=Platform text) and the add-field composer appending a new "Sprint" field live.Follow-up
select-type fields with options, delete/rename of field definitions, and showing custom fields on the card face.🤖 Generated with Claude Code