1765a4f74b
* feat(boards): enhance project selection with multi-select logic - Update BoardPanelCfg to use projectIds array instead of single projectId - Implement multi-project filtering logic in BoardPanelComponent - Enhance SelectProjectComponent with connected multi-select checkbox logic - Add migration logic in sanitizePanelCfg to handle legacy board data - Update and verify all related unit tests * fix(boards): enhance panel migration and canonicalize project selection - Prefer legacy projectId during migration even if projectIds is defaulted - Canonicalize any projectIds containing "" back to [""] (All Projects) - Add regression tests for migration and canonicalization * fix(boards): prevent project assignment for All Projects panels - Ignore project IDs for additionalTaskFields when "" is present in projectIds - Add regression tests for multi-project filtering and task assignment * fix(boards): update board form spec to match projectIds changes * test(e2e): fix outdated keyboard shortcut and comment in add-to-today test * fix(boards): translate defaultLabel in SelectProjectComponent * docs(boards): document lossy canonicalization and legacy preference * refactor(boards): simplify additionalTaskFields and remove redundant test * feat(boards): add projectIds helper functions * refactor(boards): use projectIds helpers across board logic * fix(boards): keep projectIds optional for legacy data validation Making `projectIds` a required field broke the typia validator on raw-data paths that run before the boards reducer's `sanitizePanelCfg` normalizes the shape. Most critically, the one-time legacy PFAPI -> op-log migration validates, repairs, then re-validates and THROWS on failure -- and data-repair.ts has no boards handling -- so every legacy panel (carrying `projectId`, no `projectIds`) would abort that migration for existing users. Keep `projectIds` optional (absent/[''] = "All Projects") so legacy data validates; `sanitizePanelCfg` still normalizes it to a defined array before it reaches any component. Helpers and the drop() guard handle the optional type. Adds a regression spec exercising the real typia validator. --------- Co-authored-by: Johannes Millan <johannes.millan@gmail.com>
4.1 KiB
Board View
A board provides a visual, column-based way to organize tasks. Boards let you view and organize tasks from different perspectives using configurable columns (like Kanban or an Eisenhower Matrix) without changing the underlying task data.
What Problem Boards Solve
Boards solve the problem of visual task organization. They provide flexible, filterable columns that let you see tasks organized in different ways—by status, priority, urgency, or any other criteria you configure—while keeping the same underlying tasks.
For example, you might have a Kanban board with "To Do", "In Progress", and "Done" columns, or an Eisenhower Matrix with "Urgent & Important", "Not Urgent & Important", "Urgent & Not Important", and "Not Urgent & Not Important" quadrants.
How Boards Work
Boards are made up of panels (columns). Each panel has:
- Filters that determine which tasks appear in that panel (by tags, completion status, scheduling, one or multiple projects, backlog status, etc.)
- Ordering that you control by dragging and dropping tasks within the panel
- Automatic updates that modify task properties when you move tasks between panels
Moving Tasks Between Columns
When you drag a task from one panel to another, the app automatically updates the task to match the target panel's configuration:
- Tags are added or removed based on the panel's tag filters
- Completion status is updated (marked done or undone) based on the panel's setting
- Project assignment is updated if the panel specifies a project
- Scheduling is updated (scheduled or unscheduled) based on the panel's setting
This means moving a task to a "Done" panel marks it complete, and moving it to a panel that requires certain tags adds those tags to the task.
Multiple Boards and Task Membership
Tasks can appear on multiple boards simultaneously. This works because:
- Each board panel independently filters tasks from active projects based on its criteria
- Tasks don't store which boards they belong to—membership is calculated dynamically
- Each panel maintains its own ordering, so a task can be in different positions on different boards
For example, a task might appear in the "Urgent" column of an Eisenhower Matrix board and also in the "In Progress" column of a Kanban board, with different positions in each.
Boards include tasks from projects that are hidden from the sidebar. Hidden projects are still active; only archived projects are removed from board task membership.
Boards Vs Projects Vs Tags
| Feature | Boards | Projects | Tags |
|---|---|---|---|
| Purpose | Visual organization with columns | Task grouping and structure | Cross-cutting categorization |
| Task Relationship | Dynamic filtering-based membership | Direct assignment (required) | Direct assignment (optional, multiple) |
| Visual | Column-based layout | Tree view in sidebar | Badge display on tasks |
| Persistence | Board configurations are saved | Project data and task assignments | Tag data and task assignments |
Boards provide a flexible visual layer on top of your existing task-project-tag structure. They let you create multiple simultaneous views of the same tasks without duplicating the underlying task data.
Default Boards
The app includes two default boards:
- Eisenhower Matrix — Organizes tasks by urgency and importance (4 quadrants)
- Kanban — Organizes tasks by workflow stage (To Do, In Progress, Done)
You can create custom boards with your own panels and filters to match your workflow.
Related
- 4.06-Project-View — How projects provide structural organization
- 4.07-Tag-View — How tags provide cross-cutting categorization
- 4.01-The-Today-View — Today's task list
- 4.03-Planner-View — Day-level planning
- 4.04-Schedule-View — Time-based scheduling