[feature request] The system should be able to handle multiple subcards within one major card #762

New Issue

OVERLORD · 2026-02-04T21:15:08+03:00

OVERLORD commented

2026-02-04 21:15:08 +03:00

Originally created by @AdrianoCLeao on GitHub (Jul 15, 2025).

Is this a feature for the backend or frontend?

Backend, Frontend

What would you like?

Planka cards currently support only plain checklist items (text + checkbox).
For projects that need granular responsibility and scheduling, this is limiting: every sub-task should become a separate card, cluttering boards and breaking the parent-task context.

Why is this needed?

The current behavior is:

Checklist items have no metadata (description, assignee, due-date, files, comments, etc.).
Only one flat checklist per card.
Converting an item to a card is the only workaround, causing board inflation.

The desired behavior is:

Each checklist item becomes a “sub-task” object with:
- title, description (Markdown), assignees[], due_date, labels[], attachments[]
- optional nested checklist (sub-sub-tasks)
UI:
- Inline editing inside the card, similar to Trello’s advanced checklist rows.
- Collapse/expand all subtasks; progress bar rolls up to parent card.
API:
- REST endpoints /cards/{id}/subtasks with CRUD, bulk update and move/reorder.
Permissions: inherit from parent card, but allow granular reassignment.

This implementation would fix some open issues as well, like:

This is definitely a major update, and I’d be happy to help implement it. First, however, we should consider how the architecture will handle it.

Other information

No response

Originally created by @AdrianoCLeao on GitHub (Jul 15, 2025). ### Is this a feature for the backend or frontend? Backend, Frontend ### What would you like? Planka cards currently support only plain checklist items (text + checkbox). For projects that need granular responsibility and scheduling, this is limiting: every sub-task should become a separate card, cluttering boards and breaking the parent-task context. ### Why is this needed? The current behavior is: * Checklist items have **no** metadata (description, assignee, due-date, files, comments, etc.). * Only one flat checklist per card. * Converting an item to a card is the only workaround, causing board inflation. The desired behavior is: * **Each checklist item becomes a “sub-task” object** with: * `title`, `description` (Markdown), `assignees[]`, `due_date`, `labels[]`, `attachments[]` * optional nested checklist (sub-sub-tasks) * UI: * Inline editing inside the card, similar to Trello’s advanced checklist rows. * Collapse/expand all subtasks; progress bar rolls up to parent card. * API: * REST endpoints `/cards/{id}/subtasks` with CRUD, bulk update and move/reorder. * Permissions: inherit from parent card, but allow granular reassignment. This implementation would fix some open issues as well, like: - #196 - #1130 - #206 This is definitely a major update, and I’d be happy to help implement it. First, however, we should consider how the architecture will handle it. ### Other information _No response_

OVERLORD commented

2026-02-04 21:15:12 +03:00

@meltyshev commented on GitHub (Jul 15, 2025):

Hi! Thanks for the feature request.

In v2, we've already added the ability to assign a single member to a task, as well as support for multiple task lists per card. More recently, we also introduced support for linking tasks to other cards - this feature hasn't been released yet, but you can try it out in the nightly version.

To be honest, I believe card linking should be sufficient if we make it convenient and intuitive to use. We're also planning to add the ability to convert a task into a card and automatically link it back to the original task - which should cover most use cases you're describing.

I'm not convinced that embedding full card-like data directly inside tasks (and supporting nested navigation and management) would be a practical or user-friendly approach. It introduces several challenges:

Filtering: If you filter the board by label or member, should that also apply to subtasks?
Discoverability: Important subtasks might be hidden, requiring users to open each card to find them.
UI complexity: Displaying every task with full card features could quickly clutter the interface and hurt usability.

That's why we believe that if a task needs richer features (like labels, markdown descriptions, or comments), it should be promoted to a full card and simply linked to the parent task.

@meltyshev commented on GitHub (Jul 15, 2025): Hi! Thanks for the feature request. In v2, we've already added the ability to assign a single member to a task, as well as support for multiple task lists per card. More recently, we also introduced support for linking tasks to other cards - this feature hasn't been released yet, but you can try it out in the `nightly` version. To be honest, I believe card linking should be sufficient if we make it convenient and intuitive to use. We're also planning to add the ability to convert a task into a card and automatically link it back to the original task - which should cover most use cases you're describing. I'm not convinced that embedding full card-like data directly inside tasks (and supporting nested navigation and management) would be a practical or user-friendly approach. It introduces several challenges: - Filtering: If you filter the board by label or member, should that also apply to subtasks? - Discoverability: Important subtasks might be hidden, requiring users to open each card to find them. - UI complexity: Displaying every task with full card features could quickly clutter the interface and hurt usability. That's why we believe that if a task needs richer features (like labels, markdown descriptions, or comments), it should be promoted to a full card and simply linked to the parent task.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#762