You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's no way to retrieve completed items for a specific project. get_todos accepts project_uuid but is incomplete-only; get_logbook and search_advanced can return completed items but accept no project filter. The only workaround is to pull the whole Logbook (or all completed-in-window items) and filter client-side, which is slow, unwieldy, and — for an LLM client — burns a large amount of context.
Why it matters
Per-project completed history is a common need for review and reporting workflows — for example, listing everything finished for a long-running project (say, a "Kitchen Reno" or a recurring "Weekly Ops" project) over the last few months, since the closed items live in the Logbook. Today the client must retrieve the entire Logbook — which can hold thousands of unrelated completed items — and discard nearly all of it to find the handful that belong to the project.
Root cause
get_logbook already fetches the entire completed set and filters by completion date in Python:
all_completed=things.tasks(status='completed', include_items=True) or []
# ...filter by stop_date in Python
The expensive full scan already happens; it just isn't narrowed by project before returning. The underlying library (things-py >= 0.0.15) already supports SQL-level project and stop_date filters in database.get_tasks, so the data can be narrowed at the source.
Proposed change (minimal)
get_logbook — add an optional project_uuid, and pass it through:
project=None preserves current behaviour; a UUID narrows the scan to one project (and items under its headings) at the SQL layer, then the existing stop_date filter applies to that small set.
search_advanced — add project (it already splats search_params into things.tasks/things.todos, so this is just adding the param and one dict entry). Optionally also add stop_date, which things-py already validates and SQL-filters, to enable completion-date-bounded queries (the same creation-vs-completion distinction get_logbook filters by creation date instead of completion date, causing most completed tasks to be invisible #46 fixed for get_logbook, generalised).
Backward compatibility
All new parameters default to None/absent, so existing calls are unchanged.
Summary
There's no way to retrieve completed items for a specific project.
get_todosacceptsproject_uuidbut is incomplete-only;get_logbookandsearch_advancedcan return completed items but accept no project filter. The only workaround is to pull the whole Logbook (or all completed-in-window items) and filter client-side, which is slow, unwieldy, and — for an LLM client — burns a large amount of context.Why it matters
Per-project completed history is a common need for review and reporting workflows — for example, listing everything finished for a long-running project (say, a "Kitchen Reno" or a recurring "Weekly Ops" project) over the last few months, since the closed items live in the Logbook. Today the client must retrieve the entire Logbook — which can hold thousands of unrelated completed items — and discard nearly all of it to find the handful that belong to the project.
Root cause
get_logbookalready fetches the entire completed set and filters by completion date in Python:The expensive full scan already happens; it just isn't narrowed by project before returning. The underlying library (
things-py >= 0.0.15) already supports SQL-levelprojectandstop_datefilters indatabase.get_tasks, so the data can be narrowed at the source.Proposed change (minimal)
get_logbook— add an optionalproject_uuid, and pass it through:project=Nonepreserves current behaviour; a UUID narrows the scan to one project (and items under its headings) at the SQL layer, then the existing stop_date filter applies to that small set.search_advanced— addproject(it already splatssearch_paramsintothings.tasks/things.todos, so this is just adding the param and one dict entry). Optionally also addstop_date, whichthings-pyalready validates and SQL-filters, to enable completion-date-bounded queries (the same creation-vs-completion distinction get_logbook filters by creation date instead of completion date, causing most completed tasks to be invisible #46 fixed forget_logbook, generalised).Backward compatibility
All new parameters default to
None/absent, so existing calls are unchanged.Environment