Skip to main content

Part 6 โ€” The "See all events" page

Every digest message (email / SMS / WhatsApp) carries one "See all events" link. It opens a public page that shows the resident all the events matching their interests, grouped by community. The message shows a capped preview; the page is the full list.

Why a dedicated endpoint (Option B), not the calendarโ€‹

The digest selects on leaf keys (groups.custom_filters_keys โˆฉ users.notify_categories). The public calendar's filterBy[customFilters] filters on vector-search-resources.filters.value, which holds human-readable labels synced from custom_filters / custom_filter_groups โ€” a different key space that never includes the leaf keys. Reusing the calendar would return the wrong (or empty) set. The See-all page therefore uses a dedicated endpoint that reruns the same leaf-key selection the digest used โ€” so the page is faithful to the message by construction.

The mechanismโ€‹

  • notify-digest-links doc (Mongo, apps/notifications/src/notify-digest/schemas/notify-digest-link.schema.ts): token ยท organizationId ยท userId ยท communityIds ยท keys ยท sentEventIds. Upserted per resident at digest time; also the dedup store for Part 4.
  • The message link is a short URL โ†’ {MANAGEMENT_WEBAPP}/notify-me?token=<token> (one short, stable link across all channels โ€” SMS/WABA-friendly).
  • Public endpoint GET /api/v2/notify-me/digest?token= (external-gateway, @SystemRateLimiterGuard by token+ip, no user auth โ€” the token is the capability, FF-gated per org). It loads the link doc and reruns the leaf-key selection, returning events grouped by community (with names + timezone).
  • Page (management-webapp/src/pages/notify-me/index.tsx, public, no-auth): a section per community; each event as a newsletter-style card (image right in LTR, title, date/time/tags, location, leader), BeWith header + footer.

Binding to the viewer's org & communitiesโ€‹

Category labels shown to a resident resolve community alias โ†’ org alias โ†’ BeWith default, bound to the org and communities the resident belongs to (see Part 1). The event content on this page is community-scoped by the same link doc.

Acceptance criteriaโ€‹

  • The page shows exactly the resident's matching events, grouped by community, and nothing that doesn't match.
  • One short link works across email / SMS / WhatsApp and resolves without a login.
  • The FF being off for the org yields an empty result.
  • A missing or expired token renders a friendly default/empty state (e.g. "this digest is no longer available" + a CTA back to the app), never a broken page โ€” the endpoint already returns an empty result rather than an error (CU-86cb0nea3).
  • The SQL short_url lifetime is โ‰ฅ the notify-digest-links TTL, so the short link never dies before the token it points to.

Open questionsโ€‹

  • Link lifetime / rotation: the doc is upserted per resident with a 60-day TTL on updatedAt; the sentEventIds array pruning + the default-page state are tracked in CU-86cb0nea3.
  • Whether the page should reflect always-current matches (live rerun) or the digest-time snapshot (current design: live rerun over the stored keys).