mirror of
https://github.com/DRYTRIX/TimeTracker.git
synced 2026-05-19 04:40:32 -05:00
MacJediWizard
6454ed4550
Companion to #606. The route validator at tasks.py:223 already calls KanbanColumn.get_valid_status_keys(), but two downstream spots still silently re-introduced the old hardcoded 5-key behaviour. 1. app/services/task_service.py:46 `VALID_STATUSES = ("todo", "in_progress", "review", "done", "cancelled")` was a class-level hardcoded tuple. create_task() at line 85 silently coerced any status not in the tuple to TaskStatus.TODO.value. So a user creating a task with initial status "on_hold" would have it quietly clamped to "todo" at the service layer even though the route accepted it. 2. app/templates/tasks/create.html and tasks/edit.html The status preview badge — both the server-rendered Jinja chain in create.html and the client-side updateBadge() JS map in both templates — hardcoded the same 5 keys. Selecting "on_hold" in the dropdown caused the JS lookup to miss and fall back to the first map entry ("To Do"), so the preview lied even before the form was submitted. Fix 1 (service): create_task() now calls KanbanColumn.get_valid_status_keys(project_id=project_id) to build the allowed set per call. The VALID_STATUSES tuple is kept as a last-ditch fallback for the table-not-yet-seeded path and extended to include "on_hold" so even the fallback matches the default seed. Fix 2 (templates): the Jinja preview chain in create.html now loops over kanban_columns to find the matching label. The JS updateBadge() map in both create.html and edit.html now generates entries from {% for col in kanban_columns %}, so any configured column key works without further code changes. 3 files, +25 / -13. No schema change, no data migration.