Send push notification for anniversaries

[dror3go]

As a user in a Gramps Web, I'd like to be able to get daily web push notifications for today's anniversaries.

• A toggle to set whether I'll get push notifications on the user settings page
• Be able to set the time of day when the notification will be sent, with a reasonable default in my local time
• Be able to set to which events I'd like to get notifications: event type (birthday, wedding, etc.)
• Be able to set common ancestor for these notifications, so that I won't get notifications about too-far events in my tree (to reduce noise on big trees)
• Clicking on the notification should open Gramps Web showing the full list of today's anniversaries

[Illia-M]

Thanks for the suggestion — I really like the idea!
As a first step, I’d be perfectly happy with email notifications, since the infrastructure for sending emails is already in place. This could work well as Stage 1 of the feature 🙂
Push notifications could definitely follow later as a more advanced option.

[elig-45]

I will start working on it.

[DavidMStraub]

Awesome! Would be great if you can share some ideas about architecture and UI, so we don't have to discuss details in the PR.

[elig-45]

Here is a proposed staged implementation plan.

This issue spans two repositories (gramps-web-api for backend data/scheduling and gramps-web for user settings/UI), so we should plan two coordinated PRs.

Stage 1: Daily anniversary email notifications

• Reuse the existing email task infrastructure and add one new periodic task that runs every hour.
• Store per-user preferences in the user DB and expose them via /api/users/-/.
• Preferences: enabled, time_local, timezone, event_types[], anchor_person, ancestor_generations, last_sent_local_date.
• We add timezone to the user profile because delivery is executed by backend jobs (not by the browser), so localStorage/browser timezone is not reliably available at send time.
• For filtering scope/noise, reuse existing relationship filter rules (IsLessThanNthGenerationAncestorOf / ...DescendantOf) when anchor_person is set.
• Build “today” anniversaries from the same date-mask logic already used in the dashboard (dates=*/M/D), then send one consolidated email per day per user.
• Email CTA should deep-link to a dedicated “Today’s anniversaries” route showing the full list, not just the dashboard preview.

Stage 2: Web push notifications

• Add a service worker and push subscription API (VAPID, subscription CRUD, opt-in permission flow).
• Reuse the exact same selection pipeline as Stage 1: same preferences, same due-user scheduler, same anniversary query.
• Notification click should open the same “Today’s anniversaries” route.

UI proposal (Settings > User)

• Add a new “Anniversary notifications” section.
• Controls: toggle (enabled), delivery time, timezone (default browser timezone), event-type multi-select, anchor person selector, ancestor generation slider.
• Keep labels generic (“Anniversary notifications”) so Stage 2 can add push without redesign.

[elig-45]

If this plan looks good, I’ll start implementation next.
Before I do, are there any points you’d like to adjust or any concerns I should address first?

[DavidMStraub]

This is a lot of stuff to add to the backend. Plus, adding cron jobs is not that easy, for Celery Beat server admins would have to add a dedicated container. Frankly I think that's overkill for something as simple as birthday reminders.

I'd suggest something much, much simpler: add an endpoint to the backend that returns anniversaries as ICS, with various filter options as you mentioned. Then, use whatever calender tool you like to set up reminders.

At some point, I think it would still be good to have Web Push notifications available to the backend (e.g. notifiy the admin on edits made by other users), but that's a separate issue.

EDIT: the most tricky part about an ICS subscription URL is that we would need a persistent auth token, which currently doesn't exist. So we need to think about the architecture for that, too.

[elig-45]

You're right, we should simplify for this issue..

I propose we pivot to this scope:

• Implement an anniversaries ICS feed endpoint in gramps-web-api (with filters: event types, anchor person, ancestor depth, etc.).
• No backend scheduler, no email reminder job, no Web Push in this issue.
• Add a minimal persistent token architecture for ICS subscriptions:
  • user-linked, revocable token
  • scope limited to anniversaries ICS (read-only)
  • token can be regenerated/revoked

Implementation split:

• PR 1 (gramps-web-api): ICS endpoint + persistent token model/endpoints.
• PR 2 (gramps-web): minimal UI in user settings to generate/revoke token and copy subscription URL.

If this direction looks good, I’ll draft the concrete API/token shape and start with the backend PR.

[elig-45]

We can keep the UI minimal:

• No need to show or copy a raw token.
• Only expose a single ICS subscription URL (already containing the token).
• Include a “Regenerate link” action to immediately invalidate the previous URL in case it was shared or leaked.

This keeps UX simpler while still providing a safe revocation path.

[elig-45]

Updated implementation plan (atomic PRs)

This work is split into three coordinated PRs:

1. Backend PR 1 — token infrastructure

gramps-project/gramps-web-api#790

• Introduces generic persistent scoped access-token infrastructure only.
• Does not include the anniversaries endpoint.

2. Backend PR 2 — ICS endpoint

gramps-project/gramps-web-api#792

• Adds GET /api/anniversaries.ics?token=....
• Uses the scoped token infrastructure introduced in gramps-project/gramps-web-api#790.
• Includes ICS filtering and endpoint tests.

3. Frontend PR — settings UI

#1007

• Adds a minimal Settings > User UI for ICS subscription link management.
• Will be aligned with the final backend API once the backend PRs are reviewed.

Current status

• Once gramps-project/gramps-web-api#790 is reviewed, I will adapt gramps-project/gramps-web-api#792, and then gramps-project/gramps-web#1007.
• gramps-project/gramps-web-api#790 is already open.
• gramps-project/gramps-web-api#792 and gramps-project/gramps-web#1007 have already been created as drafts.