Standard-To-Do-Liste — Prioritäts-Icon zum Durchschalten + Prioritäts-Untermenü in den Einstellungen #152
Labels
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
robert/todo#152
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Story: Standard-To-Do-Liste — Prioritäts-Icon zum Durchschalten + Prioritäts-Untermenü in den Einstellungen
As a Nutzer der Standard-To-Do-Liste,
I want to die Priorität eines Todos direkt per Klick auf ein Icon in der Zeile durchschalten
können, und alternativ über das "⋯"-Menü gezielt eine Priorität auswählen,
so that ich die Priorität schneller ändern kann, ohne den Bearbeiten-Dialog öffnen zu müssen.
Background
Die Prioritätsstufen selbst existieren bereits (
#15). Es fehlt eine schnelle Bedienmöglichkeitdirekt in der Zeile.
Acceptance criteria:
Priorität visuell darstellt (z. B. Farbe/Symbol je Stufe).
Reihenfolge durch (zyklisch).
mit allen verfügbaren Prioritätsstufen zur direkten Auswahl zeigt (nicht nur Durchschalten).
Bearbeiten-Dialog.
aktueller/neuer Priorität).
Out of scope for this story:
Claiming this issue. Plan: add a per-row priority indicator icon next to the existing "..." menu button on each Standard-Todoliste row that cycles to the next priority level on click, plus a "Priority" submenu inside the existing "..." menu for direct selection of any level. Both paths call the same backend command the edit dialog already uses. Icon/menu item get aria-labels stating current/target priority.
Fixed in
1687a2e(with e2e fixes in055bdae).Scope: added a clickable priority icon next to each Todo rows "..." menu (replaces the old plain, non-interactive dot) that cycles High/Normal/Low on click; converted the existing single cycling "Priority" menu item into this codebases first Radix DropdownMenuSub submenu, offering direct selection of any level rather than only cycling. Both paths share one setPriority() helper calling the same SetTodoPriorityCommand the old single item used. Icon and menu item both carry aria-labels stating current/next priority (icon) and are accessibly labeled via their visible text (submenu trigger/items).
Added DropdownMenuSub/SubTrigger/SubContent to the shared ui/dropdown-menu.tsx wrapper, following its existing shadcn-style pattern.
Code review (5 parallel finder agents, 8 angles) found and fixed 5 real issues before merging: a stale e2e spec assuming the old single-click-cycles-in-the-menu behavior; the new icon missing this files own established 44px touch-target and focus-visible-ring conventions; no in-flight guard against rapid double-clicks (mirrors the existing titleSavingRef/descriptionSavingRef pattern); and no readOnly guard on an archived list (now a native disabled on both the icon and every submenu item).
Fixing the e2e spec surfaced a second, CI-only issue: a real Playwright click on the new submenu trigger raced Radixs own hover-intent open logic and flaked on the Desktop HD leg. Fixed by opening the submenu via keyboard (focus + ArrowRight) instead, which is deterministic - documented as a QA-agent learned pattern for future Radix submenu testing.
Tests: TodoItem.test.tsx grew from 76 to 79 tests (icon cycling, submenu direct-selection incl. skipping intermediate levels, disabled-current-level, in-flight guard, readOnly guard), all exercised against real Radix primitives via Testing Library, not mocks. Full frontend suite (1133 tests) and dotnet build both green. CI fully green as of
194f07f(backend, frontend, and the full 4-leg E2E matrix including the fixed todo-priority.spec.ts).Local review container rebuild skipped this cycle - Docker has no working daemon in this sandbox (confirmed via a direct client-vs-server version check), and this change has no backend/DB surface to exercise there anyway; verified instead via the frontend test suite and real Gitea Actions CI.