3.9 KiB
3.9 KiB
Phase 8: Task Delete - Context
Gathered: 2026-03-18 Status: Ready for planning
## Phase BoundaryAdd a delete action to tasks with smart behavior: hard delete (remove from DB) if the task has never been completed, soft delete (deactivate, hide from views) if the task has been completed at least once. Preserves completion history for future statistics. No UI to view or restore archived tasks in this phase.
## Implementation DecisionsDelete placement
- Red delete button at the bottom of the task edit form, below the history section, separated by a divider
- Edit mode only — no delete button in create mode (user can just back out)
- No swipe-to-delete, no long-press context menu, no AppBar icon — form only
- Deliberate action: user must open the task, scroll down, and tap delete
Confirmation dialog
- Single generic "Aufgabe löschen?" confirmation — same message for both hard and soft delete
- User does not need to know the implementation difference (permanent vs deactivated)
- Follow existing room delete dialog pattern: TextButton cancel + FilledButton with error color
- Existing l10n strings (taskDeleteConfirmTitle, taskDeleteConfirmMessage, taskDeleteConfirmAction) already defined
Delete behavior
- Check task_completions count before deleting
- 0 completions → hard delete: remove task and completions from DB (existing deleteTask DAO method)
- 1+ completions → soft delete: set isActive = false on the task, task hidden from all active views
- Need new
isActiveBoolColumn on Tasks table with default true + schema migration
Post-delete navigation
- Pop back to the room task list (same as save behavior)
- Reactive providers will auto-update to reflect the deleted/deactivated task
Archived task visibility
- Soft-deleted tasks are completely hidden from all views — no toggle, no restore UI
- Archived tasks preserved in DB purely for future statistics phase
- No need to build any "show archived" UI in this phase
Claude's Discretion
- Migration version number and strategy
- Exact button styling (consistent with Material 3 error patterns)
- Whether to add a SnackBar confirmation after delete or just navigate back silently
- User explicitly wants simplicity: "just have a delete function keep it simple"
- The smart hard/soft behavior is invisible to the user — they just see "delete"
- Keep the flow dead simple: open task → scroll to bottom → tap delete → confirm → back to list
<code_context>
Existing Code Insights
Reusable Assets
TasksDao.deleteTask(taskId): Already implements hard delete with cascade (completions first, then task)TaskActionsNotifier.deleteTask(taskId): Provider method exists, calls DAO- Room delete confirmation dialog (
rooms_screen.dart:160-189): AlertDialog pattern with error-colored FilledButton - German l10n strings already defined: taskDeleteConfirmTitle, taskDeleteConfirmMessage, taskDeleteConfirmAction
Established Patterns
- Confirmation dialogs: AlertDialog with TextButton cancel + error FilledButton
- DAO transactions for cascade deletes
- ConsumerStatefulWidget for screens with async callbacks
- Schema migrations in database.dart with version tracking
Integration Points
task_form_screen.dart: Add delete button after history ListTile (edit mode only)tasks_dao.dart: Add softDeleteTask method (UPDATE isActive = false) alongside existing hard deleteTaskcalendar_dao.dart: 6 queries need WHERE isActive = true filtertasks_dao.dart: watchTasksInRoom needs WHERE isActive = true filterdatabase.dart: Add isActive BoolColumn to Tasks table + migration- All existing tasks must default to isActive = true in migration
</code_context>
## Deferred IdeasNone — discussion stayed within phase scope
Phase: 08-task-delete Context gathered: 2026-03-18