Thomas Faour
14c47aa2a0
Tasks widgets could only ever point at one CalDAV task list (a radio- button picker, owner-only). Now they merge any number of included task lists across every linked user, same checkbox-inclusion + optional pinned-color shape a calendar widget already has for its calendars -- FrameTaskList mirrors FrameCalendar exactly, down to the same owner- adds/anyone-mutes permission split (api_widget_task_list_select/ api_widget_task_list_color). Reused calendar_render._event_colors/ _draw_color_bar as-is for the per-task color bar -- a task dict's owner_display_name/color_index is exactly that function's single- source fallback shape. Also added an opt-in "show tasks completed in the last 24 hours" toggle (TaskWidgetConfig.show_completed): caldav_client.fetch_tasks now accepts a completed_since cutoff and returns completed VTODOs (with their completion time) instead of silently dropping them, and _draw_tasks gives a completed task a filled checkbox + muted text instead of the normal empty-box/due-date row. Migration 18 splits the single-source TaskWidgetConfig columns (added by 17, splitting tasks out of the calendar widget in the first place) into frame_task_lists, carrying forward each widget's existing single source as its first included list -- same shape migration 9 used carrying forward frame_calendars' old single opt-in. Verified live in the browser (desktop + mobile): the new "Included task lists" + "Recently completed" dialog sections, the show_completed toggle actually persisting through a real HTTP round-trip, and no regression in the calendar widget's own "Included calendars" dialog. Full suite (192 tests, including new merge_tasks/config_save/migration coverage) passes.
42 lines
1.8 KiB
Python
42 lines
1.8 KiB
Python
"""Tasks widget: a simple outstanding-task checklist merged from one or
|
|
more of its linked users' CalDAV task lists, in its own region -- split
|
|
out of the calendar widget's old week-view-only, single-list task list
|
|
(see models.TaskWidgetConfig) so a task list can be placed and sized on
|
|
its own, independent of any calendar's view/footprint, and can merge
|
|
more than one person's list the same way a calendar widget merges more
|
|
than one person's calendar (see models.FrameTaskList).
|
|
|
|
No "enabled" concept and no button actions: the widget's mere presence
|
|
on the grid is the on/off switch (same as every other widget type), and
|
|
its cache refreshes on the same throttled schedule as weather -- nothing
|
|
here to advance/back/force. No placeholder for "nothing included yet"
|
|
either -- same posture as app/widgets/calendar.py, which this otherwise
|
|
mirrors closely: render() always draws through get_or_refresh_tasks_
|
|
for_widget's result even when it's [], showing "Nothing outstanding"
|
|
rather than a distinct not-configured state (the dialog's preview
|
|
endpoint is what actually 400s for that case, same asymmetry calendar
|
|
already has)."""
|
|
|
|
from __future__ import annotations
|
|
|
|
from PIL import Image
|
|
from sqlalchemy.orm import Session
|
|
|
|
from ..calendar_render import _build_tasks
|
|
from ..models import Frame, Widget
|
|
from ..routers.common import get_or_refresh_tasks_for_widget
|
|
|
|
ACTION_LABELS: dict[str, str] = {}
|
|
|
|
|
|
def render(db: Session, frame: Frame, widget: Widget, target_w: int, target_h: int,
|
|
is_normal_wake: bool = True) -> Image.Image:
|
|
"""is_normal_wake is unused here -- see app/widgets/photos.py's
|
|
identical note; every widget type's render() shares one call
|
|
signature regardless of which ones actually care."""
|
|
tasks = get_or_refresh_tasks_for_widget(db, frame, widget)
|
|
return _build_tasks(tasks, target_w, target_h, frame.palette_rgb)
|
|
|
|
|
|
ACTIONS: dict = {}
|