- Go 63.7%
- TypeScript 26.8%
- CSS 5.2%
- JavaScript 3.1%
- Makefile 1.2%
mohlec
6db687af3e
All checks were successful
Build Slash Reminders Plugin / build (push) Successful in 5m43s
Wires the DELETE endpoint that had no caller. The reason for keeping it turned out not to be the undo it was originally specced for. Done and Archive both preserve the row and its text forever, just in a different tab. So a CSR who types a customer's phone number or address into a reminder currently has no way to get rid of it — archiving keeps it in the database indefinitely. That is a real gap, and a far better justification for the endpoint than "undo" ever was. I had recommended deleting the route on the grounds that undo was thin value, which was true but was the wrong question. Design of the control: - Two clicks. The second is labelled "Delete for good", not "OK", so the button says what it does instead of asking for agreement to something unstated. - The armed confirmation stays visible even when the pointer leaves the row. Hover-hiding a destructive prompt is a trap: the mouse drifts, the prompt disappears, and the next click lands on whatever took its place. - Rendered as a compact × rather than a fifth word-button. A narrow sidebar has no room for five labels, and the destructive action should not be the thing the eye lands on first. - Available on pending rows as well as completed and archived ones. The regret-what-I-typed case is most acute immediately after typing it, and Archive-then-find-it-in-another-tab is a poor answer to that. Also closes the last unexercised mutation endpoint: every route in the API now has a caller in the UI. Webapp typecheck, 8 schedule assertions and production build all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| public | ||
| server | ||
| webapp | ||
| .gitattributes | ||
| .gitignore | ||
| CHANGELOG.md | ||
| Makefile | ||
| plugin.json | ||
| README.md | ||
Slash Reminders
A Reminders surface for Slash Chat: see your pending reminders, edit and reschedule them, snooze them, check them off, and archive them — plus create standalone reminders that aren't attached to any message.
The server already stores reminders and already delivers them. What it has never had is a list: once a reminder is set, there is no way to view, change or complete it. This plugin adds that.
How it fits together
The post menu's built-in Remind stays exactly as it is, on web and mobile, and remains the normal way to create a message reminder. This plugin does not modify it. Instead, a background job moves rows out of the server's own reminder table into the plugin's table and takes over scheduling from there — so everything set the normal way shows up in the list, and the plugin owns edit, snooze, complete and archive.
Two properties of that design worth knowing:
- Reminders fire more precisely. The built-in scheduler ticks every 5 minutes on 5-minute boundaries; this plugin ticks every minute.
- It degrades safely. If the plugin is disabled or crashes, rows simply stay in the server's table and the built-in scheduler delivers them exactly as before. The failure mode is "the list stops updating", never "reminders stop working".
Reminders are delivered as a direct message from the reminders bot to the
person who set them — never to a channel, and never to a group DM, regardless of
where the reminded-about message lives.
Surfaces
| Where | What |
|---|---|
| Web | App Bar icon opens a Reminders panel in the right-hand sidebar, with Upcoming / Completed / Archived tabs |
| Web | + New reminder composer for standalone reminders |
| Mobile | Create via the built-in post menu; act on a fired reminder with Done / Snooze 1h buttons on the DM |
| Mobile | A review-and-manage page, opened in the phone's browser from the channel header |
Build
Requires Go and Node.
make check # go vet + go test + webapp typecheck — run before claiming done
make bundle # produces dist/com.ncwcom.slash-reminders-<version>.tar.gz
Install onto a running server:
make install MM_HOST=https://your-server MM_TOKEN=your-admin-token
CI builds main on every push and publishes a rolling latest release with the
bundle attached; tagging v* cuts a versioned release.
Status
Early. The scaffold and CI are in place; the schema, drain job, scheduler, API
and panel are being built in order. Planning docs, task breakdown and the
architecture decision records are kept in the private slash-deploy repo.