Add tasks multi-view dashboard design spec
This commit is contained in:
Arthur Belleville
parent
dd6e5b7d64
commit
1a00f84364
1 changed files with 374 additions and 0 deletions
|
|
@ -0,0 +1,374 @@
|
|||
# Go Backend Tasks Multi-View Dashboard Design
|
||||
|
||||
**Date:** 2026-05-10
|
||||
|
||||
**Goal**
|
||||
|
||||
Replace the current simple `/tasks` CRUD page in `go-backend` with a richer owner-level tasks dashboard that aggregates tasks across every tablo owned by the signed-in user and renders three server-side views:
|
||||
|
||||
- `Tableau`
|
||||
- `Liste`
|
||||
- `Roadmap`
|
||||
|
||||
The page should use query params as the source of truth for view state and filtering, while keeping task creation, editing, and deletion inside the existing server-rendered and HTMX-friendly backend architecture.
|
||||
|
||||
**Context**
|
||||
|
||||
The current tasks vertical slice already exists in `go-backend`:
|
||||
|
||||
- owner-scoped task and etape persistence is implemented
|
||||
- `/tasks` already supports create, edit, update, and delete
|
||||
- the page is currently rendered as a simple grouped CRUD view
|
||||
|
||||
This work does not redesign the persistence model. It redesigns the `/tasks` page contract, its server-side view shaping, and the related create/edit flows so the route behaves like a personal cross-tablo dashboard.
|
||||
|
||||
**Scope**
|
||||
|
||||
- Work exclusively in `go-backend`
|
||||
- Replace the current `/tasks` page with a server-rendered dashboard
|
||||
- Aggregate tasks across all tablos owned by the current user
|
||||
- Support three server-rendered views on the same route:
|
||||
- `kanban`
|
||||
- `list`
|
||||
- `roadmap`
|
||||
- Support URL-driven state with query params
|
||||
- Implement functional filtering for:
|
||||
- `tablo`
|
||||
- `assignee`
|
||||
- `status`
|
||||
- Extend create and edit forms to include:
|
||||
- `tablo_id`
|
||||
- `parent_task_id`
|
||||
- `assignee_id`
|
||||
- `due_date`
|
||||
- `status`
|
||||
- `title`
|
||||
- `description`
|
||||
- Constrain selectable etapes to the chosen tablo during create and edit
|
||||
- Implement two roadmap sub-modes:
|
||||
- `week`
|
||||
- `month`
|
||||
|
||||
**Out Of Scope**
|
||||
|
||||
- Drag and drop
|
||||
- Client-only tab switching
|
||||
- Calendar view
|
||||
- Reordering tasks or etapes
|
||||
- Persisted synthetic "Sans étape" rows
|
||||
- New JSON API endpoints
|
||||
- Collaborator or RBAC expansion beyond owner-only access
|
||||
- Comments, attachments, activity feeds, or task detail pages
|
||||
|
||||
**Architecture**
|
||||
|
||||
The feature should stay inside the current Go server-rendered stack:
|
||||
|
||||
- HTTP handlers in `go-backend/internal/web/handlers/`
|
||||
- page and component rendering in `go-backend/internal/web/views/`
|
||||
- task shaping and task-related helpers in `go-backend/internal/tasks/` or closely related view-model code
|
||||
- existing repository methods reused or extended only as needed
|
||||
|
||||
The core architectural move is to split `/tasks` rendering into:
|
||||
|
||||
1. one shared page-state parser
|
||||
2. one shared filtered task dataset
|
||||
3. three pure view-specific shaping functions
|
||||
|
||||
Recommended shaping functions:
|
||||
|
||||
- `buildKanbanView(...)`
|
||||
- `buildListView(...)`
|
||||
- `buildRoadmapView(...)`
|
||||
|
||||
This keeps filtering and ownership logic centralized while isolating presentation-specific grouping rules.
|
||||
|
||||
**Route Contract**
|
||||
|
||||
The route remains `GET /tasks`, but the page state is now controlled by query params.
|
||||
|
||||
Supported query params:
|
||||
|
||||
- `view=kanban|list|roadmap`
|
||||
- `roadmap_mode=week|month`
|
||||
- `tablo=<tablo_id>` optional, repeatable
|
||||
- `assignee=<user_id>` optional, repeatable
|
||||
- `status=todo|in_progress|in_review|done` optional, repeatable
|
||||
|
||||
Default behavior:
|
||||
|
||||
- missing or invalid `view` falls back to `kanban`
|
||||
- missing or invalid `roadmap_mode` falls back to `week`
|
||||
- invalid filter values are ignored rather than breaking the page
|
||||
- `roadmap_mode` is ignored when `view` is not `roadmap`
|
||||
|
||||
The page should remain shareable and refresh-safe:
|
||||
|
||||
- filter changes submit with `GET /tasks`
|
||||
- tabs are links that preserve the current applicable filters
|
||||
- roadmap mode toggles are links or GET forms that preserve filters
|
||||
|
||||
**Data Scope**
|
||||
|
||||
All three views consume the same owner-scoped task set:
|
||||
|
||||
- every active task across every tablo owned by the signed-in user
|
||||
- every active etape required to label or group those tasks
|
||||
|
||||
This is intentionally not a single-tablo page. `/tasks` is a personal dashboard over the user’s full owned workload.
|
||||
|
||||
**Shared Page Shell**
|
||||
|
||||
The page shell should render:
|
||||
|
||||
- page title
|
||||
- `Nouvelle tâche` action
|
||||
- view tabs:
|
||||
- `Tableau`
|
||||
- `Liste`
|
||||
- `Roadmap`
|
||||
- roadmap sub-mode toggle when `view=roadmap`
|
||||
- filter controls for:
|
||||
- tablo
|
||||
- assignee
|
||||
- status
|
||||
|
||||
The shell also needs the option data required to render forms and filters:
|
||||
|
||||
- all owner tablos
|
||||
- all relevant assignee options
|
||||
- status options
|
||||
- tablo-scoped etape options for create and edit forms
|
||||
|
||||
**Kanban View Design**
|
||||
|
||||
The kanban view is status-driven and cross-tablo.
|
||||
|
||||
Columns:
|
||||
|
||||
- `À faire`
|
||||
- `En cours`
|
||||
- `Vérification`
|
||||
- `Terminé`
|
||||
|
||||
Each column contains task cards from all owned tablos matching that status.
|
||||
|
||||
Each card should show enough metadata to make a cross-tablo dashboard usable:
|
||||
|
||||
- title
|
||||
- tablo name
|
||||
- étape label, or `Sans étape`
|
||||
- due date if present
|
||||
- assignee if present
|
||||
|
||||
First pass interaction is explicit-action based:
|
||||
|
||||
- no drag and drop
|
||||
- status changes happen through edit actions or other explicit server-backed controls
|
||||
|
||||
**List View Design**
|
||||
|
||||
The list view is grouped by status across all owned tablos.
|
||||
|
||||
Groups:
|
||||
|
||||
- `À faire`
|
||||
- `En cours`
|
||||
- `Vérification`
|
||||
- `Terminé`
|
||||
|
||||
Inside each group, tasks are rendered as flat rows rather than nested by tablo or étape.
|
||||
|
||||
Each row should show:
|
||||
|
||||
- title
|
||||
- tablo
|
||||
- étape or `Sans étape`
|
||||
- assignee if present
|
||||
- due date if present
|
||||
- status actions and edit/delete access as appropriate
|
||||
|
||||
This view is intentionally a personal workload list rather than a single-tablo breakdown.
|
||||
|
||||
**Roadmap View Design**
|
||||
|
||||
The roadmap view is grouped horizontally by étape lanes and bucketed by due date.
|
||||
|
||||
Lane rules:
|
||||
|
||||
- lanes represent `tablo + étape`
|
||||
- the lane identity must include the tablo to avoid collisions between same-named etapes in different tablos
|
||||
- tasks without a parent etape go into a synthetic per-tablo lane:
|
||||
- `Tablo name / Sans étape`
|
||||
|
||||
Bucket rules:
|
||||
|
||||
- tasks are grouped inside each lane by due date
|
||||
- tasks without a due date go into a final `Sans date` bucket
|
||||
|
||||
Roadmap sub-modes:
|
||||
|
||||
- `week`
|
||||
- weekly buckets starting from today, May 10, 2026
|
||||
- `month`
|
||||
- monthly buckets starting from the current month containing May 10, 2026
|
||||
|
||||
Past-due tasks:
|
||||
|
||||
- tasks with due dates before the current starting point should still remain visible
|
||||
- they should be folded into the first visible bucket rather than disappearing into an unrendered past section
|
||||
|
||||
This preserves visibility without introducing a separate "past" axis in the first pass.
|
||||
|
||||
**Filter Behavior**
|
||||
|
||||
Filters must apply consistently across all three views.
|
||||
|
||||
Required filters:
|
||||
|
||||
- `tablo`
|
||||
- `assignee`
|
||||
- `status`
|
||||
|
||||
Behavior:
|
||||
|
||||
- filters are applied once to the shared task set before view-specific grouping
|
||||
- switching between `kanban`, `list`, and `roadmap` preserves active filters where possible
|
||||
- switching roadmap sub-modes preserves active filters
|
||||
|
||||
Invalid filters:
|
||||
|
||||
- unknown tablo IDs are dropped
|
||||
- unknown assignee IDs are dropped
|
||||
- unknown status values are dropped
|
||||
|
||||
The page should always normalize back to a valid state instead of failing.
|
||||
|
||||
**Create And Edit Flow**
|
||||
|
||||
Because `/tasks` is now cross-tablo, create and edit forms must include tablo selection.
|
||||
|
||||
Create form fields:
|
||||
|
||||
- `tablo_id`
|
||||
- `title`
|
||||
- `description`
|
||||
- `status`
|
||||
- `due_date`
|
||||
- `assignee_id`
|
||||
- `parent_task_id`
|
||||
|
||||
Edit form fields:
|
||||
|
||||
- `tablo_id`
|
||||
- `title`
|
||||
- `description`
|
||||
- `status`
|
||||
- `due_date`
|
||||
- `assignee_id`
|
||||
- `parent_task_id`
|
||||
|
||||
Tablo and étape coupling:
|
||||
|
||||
- once a tablo is chosen, selectable etapes must be limited to active etapes from that tablo only
|
||||
- `Sans étape` remains a runtime concept, represented by `parent_task_id = null`
|
||||
|
||||
The chosen tablo and étape combination must be enforced on the server even if the browser submits an invalid combination.
|
||||
|
||||
**Validation Rules**
|
||||
|
||||
The dashboard should reuse the current task invariants and add page-specific validation.
|
||||
|
||||
Required server-side rules:
|
||||
|
||||
- `parent_task_id` must be null or point to an active etape
|
||||
- `parent_task_id` must belong to the selected `tablo_id`
|
||||
- a task cannot point to an etape from another tablo
|
||||
- `assignee_id` must resolve to a valid selectable user
|
||||
- invalid `view` and `roadmap_mode` values fall back to defaults
|
||||
|
||||
When editing a task:
|
||||
|
||||
- if the selected tablo changes, the selected parent etape must be revalidated against the new tablo
|
||||
- if the current parent no longer belongs to the selected tablo, the mutation must be rejected
|
||||
|
||||
Delete behavior remains unchanged functionally:
|
||||
|
||||
- delete the task or etape
|
||||
- re-render the page in the current normalized query state
|
||||
|
||||
**Rendering Strategy**
|
||||
|
||||
The page should keep the current server-driven model:
|
||||
|
||||
- full-page render for normal requests
|
||||
- content fragment render for HTMX requests where appropriate
|
||||
- create and edit forms can continue to use modal or inline fragment responses
|
||||
|
||||
The important change is not the transport mechanism. It is the introduction of explicit page-state modeling and isolated per-view presenters.
|
||||
|
||||
Recommended internal page-state model:
|
||||
|
||||
- selected `view`
|
||||
- selected `roadmap_mode`
|
||||
- selected tablo filters
|
||||
- selected assignee filters
|
||||
- selected status filters
|
||||
|
||||
Recommended shared view-model layers:
|
||||
|
||||
- page shell view model
|
||||
- create/edit form view model
|
||||
- `kanban` view model
|
||||
- `list` view model
|
||||
- `roadmap` view model
|
||||
|
||||
**Testing**
|
||||
|
||||
Testing should cover both state parsing and view grouping behavior.
|
||||
|
||||
Handler tests:
|
||||
|
||||
- default `/tasks` render
|
||||
- `view=kanban`
|
||||
- `view=list`
|
||||
- `view=roadmap`
|
||||
- `roadmap_mode=week`
|
||||
- `roadmap_mode=month`
|
||||
- filter combinations for:
|
||||
- tablo
|
||||
- assignee
|
||||
- status
|
||||
- create flow with `tablo_id`
|
||||
- edit flow with `tablo_id`
|
||||
- invalid cross-tablo parent étape rejection
|
||||
|
||||
View-model tests where practical:
|
||||
|
||||
- kanban grouping by status across multiple tablos
|
||||
- list grouping by status across multiple tablos
|
||||
- roadmap lane identity uses `tablo + étape`
|
||||
- synthetic `Sans étape` lanes are created per tablo
|
||||
- `Sans date` bucket is rendered
|
||||
- overdue tasks are placed in the first visible roadmap bucket
|
||||
|
||||
**Implementation Slices**
|
||||
|
||||
1. Extend `/tasks` query parsing and normalized page-state handling.
|
||||
2. Build shared filter-option loading for tablos, assignees, and statuses.
|
||||
3. Introduce a shared owner-level filtered task dataset.
|
||||
4. Split rendering into `kanban`, `list`, and `roadmap` view-model builders.
|
||||
5. Replace the current simple `/tasks` view with a page shell and mode-specific renderers.
|
||||
6. Extend create and edit forms with `tablo_id` and tablo-scoped etape options.
|
||||
7. Add tests for filtering, grouping, roadmap bucketing, and invalid parent validation.
|
||||
|
||||
**Recommendation**
|
||||
|
||||
Use one `/tasks` route with shared filtering and separate presenter functions for each mode.
|
||||
|
||||
This approach fits the current Go backend architecture best because it:
|
||||
|
||||
- keeps the URL as the source of truth
|
||||
- avoids duplicated repository and filter logic
|
||||
- keeps each view’s grouping logic isolated
|
||||
- preserves server-rendered behavior without introducing a browser-side state machine
|
||||
Loading…
Reference in a new issue