Fix tasks history retention: UI filter + DB cleanup (tasks_history_delay)

[guerricv]

Context

TeamPass has two distinct data sets related to the Task Manager:

• Task execution logs (technical logs) stored in teampass_background_tasks_logs, controlled by tasks_log_retention_delay (days).
• Tasks history (the “Done” tab / completed & failed tasks) stored in teampass_background_tasks and teampass_background_subtasks, controlled by tasks_history_delay (stored in seconds, displayed as days in the UI).

The UI parameter “Tasks history retention (in days)” was not consistently applied: some records were displayed far beyond the configured retention and database cleanup was incomplete. Additionally, failed tasks were being removed by a separate cleanup path using a fixed ~15-day rolling cutoff, which caused the oldest “Done” entries to disappear minute-by-minute.

Root cause

• UI “Tasks history retention” default mismatch: the Tasks settings page mixed seconds vs days in the default value, leading to inconsistent behavior.
• Missing DB cleanup for tasks history: old finished tasks (and related subtasks) were not deleted according to tasks_history_delay.
• Failed tasks cleanup was not aligned with the setting: scripts/background_tasks___handler.php removed status='failed' tasks using a rolling cutoff based on an internal/fallback value (~15 days) instead of tasks_history_delay.

Changes

1. pages/tasks.php
   • Fix “Tasks history retention” input default so it is consistently displayed/handled in days.
2. sources/logs.datatables.php
   • Filter the “Done” tab results using tasks_history_delay (seconds) to match the configured retention window.
   • Note: I kept the previous condition (finished_at != "") unchanged in my local setup to minimize risk. It may be more robust to use finished_at > 0 given the schema stores timestamps as strings, but I’m leaving this decision to maintainers.
3. scripts/background_tasks___functions.php
   • Add DB cleanup for tasks history based on tasks_history_delay: delete old finished tasks from background_tasks and related rows in background_subtasks.
   • Safety: if tasks_history_delay is unexpectedly stored in days, auto-convert to seconds.
   • Ensure cleanup runs only once per PHP process (doLog can be called multiple times per run).
4. scripts/background_tasks___handler.php
   • Align status='failed' cleanup with tasks_history_delay (instead of the hardcoded/fallback ~15 days), so failed tasks are retained consistently with the Task Manager history setting.
   • Small hardening: ensure finished_at > 0 when removing old failed tasks.

How it was validated

• Updated tasks_history_delay and confirmed the “Done” tab immediately reflects the configured retention window.
• Verified DB cleanup removes finished tasks older than the configured threshold and keeps newer ones.
• Verified the unexpected “minute-by-minute” disappearance of the oldest entries was caused by the failed-tasks cleanup query:

  DELETE t, st ... WHERE t.finished_at < (now - ~15 days) AND t.status = 'failed'

  After this change, the same query uses a cutoff consistent with tasks_history_delay (e.g. ~60 days).

Notes / considerations

• Retention is destructive by design: if the retention value is temporarily lowered (e.g. 7/15 days), older history will be deleted and will not reappear when increasing the value later.