Pick webhook and tracer events by group, with common picks

jcoffey-dev commented

2026-09-28 22:10:38 +00:00

Owner

Last second-wave item from the settings-reorg spec. Stacked on #47 (ports table), since both touch MainContent.tsx: merge #47 first.

Event picker. Every form field that takes a set of EventType (webhooks, tracers) replaces the flat 649-item multi-select with:

events grouped by category, with plain group names (Sign-in, Outgoing delivery, Security, Certificates (ACME)…) and a tri-state switch for the whole group, with counts;
a search over names, labels, the server's explanations and group names ("bounce" finds the double-bounce, queued-DSN and DKIM2-DSN events);
each event's label, name and explanation;
common picks: delivery results, failed sign-ins and bans, alerts (telemetry.alert-event/-message), spam verdicts, certificates. All the names were checked against the schema.

Webhooks page. It opens with What a webhook receives:

the JSON shape the server posts, {"events":[{"id","createdAt","type","data"}]} (trc JSON serializer, with_id/with_spans), with data described rather than invented;
how X-Signature is computed: HMAC-SHA256 of the raw body, base64;
how to see one arrive: pick Failed sign-ins and bans and sign in once with a wrong password.

No "send test". The server has no call to fire a webhook, and posting from the browser wouldn't test the server. A server-side test call could come later.

Checked: unit tests for grouping and search (493 total), plus typecheck, lint and build. In Chrome against a local server:

the picker rendered in Create webhook;
Failed sign-ins and bans chose 6 events, and the search matched explanations;
the webhook saved with exactly those six events (eventsPolicy: include) and was then removed;
the Webhooks page card rendered above the list.

English only: about 20 UI strings, 44 group names and 5 picks.

Last second-wave item from the settings-reorg spec. **Stacked on #47** (ports table), since both touch `MainContent.tsx`: merge #47 first. **Event picker.** Every form field that takes a set of `EventType` (webhooks, tracers) replaces the flat 649-item multi-select with: - events grouped by category, with plain group names (Sign-in, Outgoing delivery, Security, Certificates (ACME)…) and a tri-state switch for the whole group, with counts; - a search over names, labels, the server's explanations and group names ("bounce" finds the double-bounce, queued-DSN and DKIM2-DSN events); - each event's label, `name` and explanation; - **common picks:** delivery results, failed sign-ins and bans, alerts (`telemetry.alert-event`/`-message`), spam verdicts, certificates. All the names were checked against the schema. **Webhooks page.** It opens with *What a webhook receives*: - the JSON shape the server posts, `{"events":[{"id","createdAt","type","data"}]}` (trc JSON serializer, `with_id`/`with_spans`), with `data` described rather than invented; - how `X-Signature` is computed: HMAC-SHA256 of the raw body, base64; - how to see one arrive: pick *Failed sign-ins and bans* and sign in once with a wrong password. **No "send test".** The server has no call to fire a webhook, and posting from the browser wouldn't test the server. A server-side test call could come later. **Checked:** unit tests for grouping and search (493 total), plus typecheck, lint and build. In Chrome against a local server: - the picker rendered in *Create webhook*; - *Failed sign-ins and bans* chose 6 events, and the search matched explanations; - the webhook saved with exactly those six events (`eventsPolicy: include`) and was then removed; - the Webhooks page card rendered above the list. English only: about 20 UI strings, 44 group names and 5 picks.

jcoffey-dev added 2 commits 2026-09-28 22:10:39 +00:00

The standard mail ports as one table, above Listeners

ci / build (pull_request) Successful in 1m24s

Details

ci / publish (pull_request) Skipped

Details

6b907e74db

Network › Listeners opens with the ports people know: 25 for receiving
mail, 587 and 465 for sending from mail apps, 443 and 80 for the web,
and IMAP, POP3 and ManageSieve. Each row says what it's for, how it's
encrypted and whether it's open, with a switch.

- Opening one adds a listener for it on every address; closing removes
  its listeners. Closing 25 or 443 asks first, saying what stops.
- IMAP, POP3 and ManageSieve, and the sending ports while legacy mail
  is off, belong to Security › Hardening, whose switches keep and
  restore their listeners; their rows link there.
- Listeners on other ports are listed as sentences, and left alone.
- A note says open means listening: the firewall and hosting provider
  decide whether the internet can reach it.

Pick webhook and tracer events by group, with common picks

ci / build (pull_request) Successful in 1m27s

Details

ci / publish (pull_request) Skipped

Details

61ab90da34

Choosing events meant a flat multi-select over 649 event types. Every
form field that takes a set of EventType (webhooks, tracers) now gets a
picker:

- the events grouped by category, named in words (Sign-in, Outgoing
  delivery, Security…), each group with a switch for all of it;
- a search that reads names, labels, explanations and group names;
- each event's label, name and the server's explanation;
- common picks: delivery results, failed sign-ins and bans, alerts,
  spam verdicts and certificates.

Monitoring › Webhooks opens with what a webhook receives: the JSON
shape the server posts ({events: [{id, createdAt, type, data}]}), how
X-Signature is computed (HMAC-SHA256 of the raw body, base64), and how
to see one arrive. There's no "send test": the server has no call for
it, and posting from the browser wouldn't test the server.

jcoffey-dev merged commit 995b24c733 into main

2026-09-28 22:12:14 +00:00

jcoffey-dev deleted branch feature/webhook-events

2026-09-28 22:12:14 +00:00

Pick webhook and tracer events by group, with common picks #48