45 lines
2.8 KiB
Markdown
45 lines
2.8 KiB
Markdown
---
|
|
id: mobile-apps/deep-link-a-todo-notification-to-its-file
|
|
title: "Deep-link a todo notification straight to that item's markdown"
|
|
theme: mobile-apps
|
|
status: open
|
|
created: 2026-08-25
|
|
date_source: stated
|
|
order: 4
|
|
---
|
|
|
|
**Deep-link a todo notification straight to that item's markdown.** Wanted 2026-08-25: pressing a
|
|
"new todo" notification should open the file directly, not just the app.
|
|
|
|
**The mechanism exists — SendOff is the precedent to copy.** The notification catalogue
|
|
(`src/servers/notifications/catalogue.ts`) already carries a `route` per entry, e.g.
|
|
`officer/core:sendoff.landed` → `officer://files?path=Documents/SendOff/{id}`. A todo entry needs the
|
|
same shape: a `route` template, and the producer (whoever calls `/notify` when a todo is filed —
|
|
today that is this session, using `officer/core:message`, which carries no route at all) supplying the
|
|
values that fill it in.
|
|
|
|
**One correction before copying that pattern: `?path=` is the OLD shape.** The file browser's own URL
|
|
model (`files-route.ts`, finished 2026-08-15) is the folder as the PATHNAME and `?view=<name>` as the
|
|
open file within it — `/files/<folder>?view=<filename>`, not a `path=` query param. A todo's route
|
|
should be built the current way: folder = `todo/<theme>`, view = `<slug>.md`. Getting this right means
|
|
reading `folderHref`/the encode helpers in `files-route.ts` rather than copying SendOff's route
|
|
literally — that one predates the model it now looks like it follows.
|
|
|
|
**Where the file actually lives is a fact worth stating rather than assuming:** `/files` is scoped to
|
|
the owner's home directory (`getRootDir` in `api/file-browser/router.ts`), and this repo's checkout
|
|
sits under it — so `todo/<theme>/<slug>.md` IS reachable, as
|
|
`officer-dev/platform/todo/<theme>/<slug>.md`. But that means the notification opens a raw file inside
|
|
a DEV CHECKOUT via the general-purpose file browser, not a document in the owner's own space.
|
|
|
|
**Open question worth deciding before building, not after:** `/todos` — the Kanban board built
|
|
2026-08-24 — already has a per-item address, `?selected=<id>`, and renders that item's markdown in a
|
|
proper detail pane with a status control, for free. A todo notification could deep-link there instead
|
|
of into the raw file browser. Both are real options; the file-browser route is what was asked for, the
|
|
board route is what already exists and reads better. Worth a one-line decision rather than defaulting
|
|
to the more literal reading.
|
|
|
|
**Also needed regardless of which target wins:** the producer side. Whatever POSTs to `/notify` when a
|
|
todo is created (this session, and eventually the memo-dispatcher pipeline) needs to know the new
|
|
item's `id` at send time and pass it through — trivial here since the id is generated in the same
|
|
breath as the file, but worth naming as a real piece of the work, not assumed.
|