# Ticket: Configure account notification subscriptions

Status: complete
Type: ticket
Updated: 2026-08-06
Next Action: none; retain with deployed notification-subscription evidence
Parent: work/wp/active/wp-build-standalone-pi-sd-qualification-operator-application.md

## Problem

Email routing is inferred from the campaign creator and has no operator-facing
configuration. The current campaign can therefore have an empty or unintended
recipient. Users cannot see which notification classes exist, opt named
accounts into them, or receive a normal qualification-completion message.

## Expected Behavior

An administrator opens a dedicated Notification settings page. It lists every
active username and its stored account email, and exposes explicit opt-ins for
operator intervention and qualification completion. Accounts without an email
remain visible but cannot be selected. Notification records remain canonical
and deduplicated, while delivery is fanned out once per subscribed account.
Completion is informational and never appears as an active operator
intervention.

## Acceptance Criteria

- [x] A staff-only Notification settings page is linked beside Manage users
      and lists username, stored email, account state, and every supported
      notification topic.
- [x] Administrators can atomically enable or disable each account/topic
      subscription; accounts without email cannot be enabled.
- [x] Intervention notifications create one canonical alert and one durable,
      deduplicated delivery per subscribed active account using the account's
      current email snapshot.
- [x] Qualification `APPROVED` and `REJECTED` transitions create one
      informational completion notification and per-subscriber deliveries;
      they do not create or override an operator action.
- [x] The worker independently retries, reminds, and escalates deliveries and
      records recipient-specific attempts without duplicating the canonical
      alert.
- [x] Acknowledging an intervention stops all remaining deliveries for that
      canonical alert.
- [x] Existing notification history is preserved through migration.
- [x] The `jon` account can be selected for `jong@sheldonmfg.com`; production
      is configured for both initial topics after deployment.
- [x] Focused and full ARM tests, migration, health, web-only deployment, live
      configuration rendering, and Controller A/worker continuity pass.

## Verification

Exercise permission denial, missing-email validation, enable/disable updates,
multi-recipient fan-out, per-recipient retries, acknowledgement, approved and
rejected completion, and card-action isolation. Run the exact ARM64 image and
migration against a disposable database before production. Back up production,
apply the migration, deploy web and notification worker only when required,
select `jon` for both topics, and verify delivery records without sending a
synthetic message unless separately requested.

Completed by SD Qualifier PRs #43 and #44. The PostgreSQL-only nullable-join
lease-lock defect found during live verification was corrected before
closeout. Final evidence is
`work/evidence/sd-qualifier-account-notification-subscriptions-20260806.md`.
