tfaour/espresso_frame
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases 13 Wiki Activity

Let a tasks widget merge multiple task lists, checkbox+color like calendar
Build and push server image / test (push) Successful in 27s
Details
Build and push server image / build-and-push (push) Successful in 2m8s
Details
Build and push server image / deploy (push) Successful in 59s
Details

Browse Source 
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.
This commit is contained in:
Thomas Faour
2026-07-25 03:39:26 +00:00
parent b5c52004c8
commit 14c47aa2a0
16 changed files with 884 additions and 326 deletions
Download Patch File Download Diff File Expand all files Collapse all files
server/app/migration.py
+83 -19
View File
@@ -25,6 +25,7 @@ from .models import (
CalendarWidgetConfig,
Frame,
FrameButtonAction,
FrameTaskList,
PhotoWidgetConfig,
ServerSettings,
TaskWidgetConfig,
@@ -438,6 +439,55 @@ def _migration_17(conn) -> None:
conn.execute(text("ALTER TABLE calendar_widget_configs_new RENAME TO calendar_widget_configs"))
def _migration_18(conn) -> None:
"""A tasks widget can now merge more than one person's CalDAV task
list, checkbox-included with an optional pinned color each -- same
multi-source shape calendar widgets already have (models.
FrameCalendar), rather than the single user_id/calendar_key pair
migration 17 gave TaskWidgetConfig when tasks first became their own
widget type. Also adds show_completed (see caldav_client.
fetch_tasks' completed_since -- off by default, so this migration
changes no widget's on-panel appearance by itself).
Each task_widget_configs row's existing single source, if any,
carries forward as that widget's first frame_task_lists row
(included) before the now-dead user_id/calendar_key columns are
dropped -- same "carry forward the old single opt-in as a row before
dropping the column" shape _migration_9 used for frame_calendars."""
conn.execute(text(
"CREATE TABLE frame_task_lists ("
"id INTEGER PRIMARY KEY, "
"widget_id INTEGER NOT NULL REFERENCES widgets(id) ON DELETE CASCADE, "
"user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE, "
"calendar_key TEXT NOT NULL, "
"calendar_label TEXT NOT NULL DEFAULT '', "
"included INTEGER NOT NULL DEFAULT 1, "
"color_index INTEGER)"
))
conn.execute(text(
"CREATE UNIQUE INDEX ix_frame_task_lists_unique ON frame_task_lists (widget_id, user_id, calendar_key)"
))
conn.execute(text(
"INSERT INTO frame_task_lists (widget_id, user_id, calendar_key, included) "
"SELECT widget_id, user_id, calendar_key, 1 FROM task_widget_configs "
"WHERE calendar_key IS NOT NULL AND user_id IS NOT NULL"
))
conn.execute(text(
"CREATE TABLE task_widget_configs_new ("
"widget_id INTEGER PRIMARY KEY REFERENCES widgets(id) ON DELETE CASCADE, "
"checked_at REAL NOT NULL DEFAULT 0.0, "
"cached TEXT, "
"show_completed INTEGER NOT NULL DEFAULT 0)"
))
conn.execute(text(
"INSERT INTO task_widget_configs_new (widget_id, checked_at, cached) "
"SELECT widget_id, checked_at, cached FROM task_widget_configs"
))
conn.execute(text("DROP TABLE task_widget_configs"))
conn.execute(text("ALTER TABLE task_widget_configs_new RENAME TO task_widget_configs"))
MIGRATIONS = [
(1, _migration_1),
(2, _migration_2),
@@ -456,6 +506,7 @@ MIGRATIONS = [
(15, _migration_15),
(16, _migration_16),
(17, _migration_17),
(18, _migration_18),
]
@@ -624,27 +675,36 @@ def _calendar_config_from_frame(frame: Frame, widget_id: int) -> CalendarWidgetC
week_days=frame.calendar_week_days,
week_layout=frame.calendar_week_layout,
week_start_offset=frame.calendar_week_start_offset,
# tasks_* deliberately not carried over -- see _task_config_from_frame,
# a sibling standalone widget now, not part of this config.
# tasks_* deliberately not carried over -- see
# _task_config_and_list_from_frame, a sibling standalone widget
# now, not part of this config.
)
def _task_config_from_frame(frame: Frame, widget_id: int) -> TaskWidgetConfig:
def _task_config_and_list_from_frame(frame: Frame, widget_id: int) -> tuple[TaskWidgetConfig, FrameTaskList]:
"""Only ever called for a frame whose legacy calendar_tasks_* columns
(see Frame's own docstring on those -- a dead pre-widget-system
field set, same status as calendar_photo_inlay below) still carry a
configured source -- i.e. a database jumping straight from before
the widget system existed to after tasks became its own widget type
in a single upgrade, skipping the intermediate period where it would
have lived on CalendarWidgetConfig instead (see _migration_17's own
extraction of *that* case)."""
return TaskWidgetConfig(
the widget system existed to after tasks became their own
multi-list widget type in a single upgrade, skipping both
intermediate periods where it would have lived on
CalendarWidgetConfig (_migration_17's extraction) and then a
single-source TaskWidgetConfig (_migration_18's extraction) instead.
Reproduces the same shape those two migrations arrive at directly:
a bare cache-state config plus one included FrameTaskList row."""
cfg = TaskWidgetConfig(
widget_id=widget_id,
user_id=frame.calendar_tasks_user_id,
calendar_key=frame.calendar_tasks_calendar_key,
checked_at=frame.calendar_tasks_checked_at,
cached=list(frame.calendar_tasks_cached) if frame.calendar_tasks_cached else None,
)
task_list = FrameTaskList(
widget_id=widget_id,
user_id=frame.calendar_tasks_user_id,
calendar_key=frame.calendar_tasks_calendar_key,
included=True,
)
return cfg, task_list
def _whiteboard_config_from_frame(frame: Frame, widget_id: int) -> WhiteboardWidgetConfig:
@@ -679,14 +739,16 @@ def _default_button_actions(frame_id: int, widget_id: int, widget_type: str) ->
def _maybe_add_legacy_tasks_widget(db, frame: Frame, existing: list[grid.Rect], next_sort_order: int) -> None:
"""Only relevant for a database jumping straight from before the
widget system existed to after tasks became its own widget type in
one upgrade (see _task_config_from_frame) -- frame.calendar_tasks_*
is the dead legacy field set otherwise. Auto-placed in whatever open
space is left after the widget(s) above it in _backfill_frame_
widgets claimed theirs, same find_open_rect logic a manual "add
widget" uses; silently dropped (logged) if none fits, same as this
migration having nowhere else to put it either."""
if not frame.calendar_tasks_calendar_key:
widget system existed to after tasks became their own widget type
in one upgrade (see _task_config_and_list_from_frame) --
frame.calendar_tasks_* is the dead legacy field set otherwise.
Requires both calendar_key and user_id (FrameTaskList.user_id is
NOT NULL) -- same guard _migration_18's own SQL extraction uses.
Auto-placed in whatever open space is left after the widget(s) above
it in _backfill_frame_widgets claimed theirs, same find_open_rect
logic a manual "add widget" uses; silently dropped (logged) if none
fits, same as this migration having nowhere else to put it either."""
if not frame.calendar_tasks_calendar_key or not frame.calendar_tasks_user_id:
return
min_w, min_h = grid.MIN_FOOTPRINT["tasks"]
rect = grid.find_open_rect(frame.orientation, existing, min_w, min_h)
@@ -701,7 +763,9 @@ def _maybe_add_legacy_tasks_widget(db, frame: Frame, existing: list[grid.Rect],
sort_order=next_sort_order, created_at=time.time())
db.add(task_widget)
db.flush()
db.add(_task_config_from_frame(frame, task_widget.id))
cfg, task_list = _task_config_and_list_from_frame(frame, task_widget.id)
db.add(cfg)
db.add(task_list)
def _backfill_frame_widgets(db, frame: Frame) -> None: