* feat(notifications): opt-in daily "nytt att bokföra" email digest Users asked for an email when new work arrives: bank transactions that synced overnight and documents that landed in the inbox. Adds a daily 05:45 UTC cron (after the 05:00 bank sync) that emails opted-in users a per-company summary with counts only, no amounts (data-minimization stance of the kvittens/skattekonto mails). - notification_settings.email_digest_enabled, NOT NULL DEFAULT false: strictly opt-in via a new toggle in the notification settings panel - notification_log type 'bookkeeping_digest' with the claim-then-send partial unique index pattern: one mail per user per company per day - counts unbooked transactions and unprocessed inbox items created in the last 24h; empty digests are never sent - brand-aware sender + link base via lib/email/brand-sender - docker crontabs regenerated from vercel.json Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122MznXxrLRyT96fGhfyzD4 * fix(notifications): digest review findings in one pass Skeptic + bot findings on PR #2078, resolved together: - Count queries now match the canonical worklist anchors: ignored transactions excluded; inbox items already booked directly or matched to a transaction (created_journal_entry_id / matched_transaction_id) no longer counted (skeptic: spurious digests). - Memberships sweep and member-email lookups chunk .in() id lists at 150 ids to stay under proxy URL limits (HTTP 414 at ~350 opted-in users). - Recoverable claim lifecycle (CodeRabbit): claim inserts as 'pending', flips to 'sent' only after the provider accepted the mail; a stale pending claim is atomically taken over by a later run, so a worker death mid-send no longer swallows the day's digest. New migration 20260831110000 admits 'pending' to the delivery_status CHECK. - Company name sanitized against CRLF header injection before the mail subject (compliance swarm ASVS V1.2.5), with test. - RoPA entry for the new processing activity in .compliance/ropa.yaml (compliance swarm GDPR Art. 30). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122MznXxrLRyT96fGhfyzD4 * fix(types): admit 'pending' to NotificationLog delivery_status union Matches migration 20260831110000; surfaced by fix re-verification. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122MznXxrLRyT96fGhfyzD4 --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
27 lines
1.2 KiB
SQL
27 lines
1.2 KiB
SQL
-- Admit 'pending' to notification_log's delivery_status CHECK.
|
|
--
|
|
-- The bookkeeping digest (20260831100000) uses a recoverable claim: the row
|
|
-- is inserted as 'pending' BEFORE the email is handed to the provider and
|
|
-- flipped to 'sent' only after the provider accepted it. A 'pending' claim
|
|
-- whose sent_at lease has gone stale marks a run that died mid-send and can
|
|
-- be taken over by a later run. The prior senders (kvittens,
|
|
-- connection-expired) insert 'sent' up front and lose the day's mail if the
|
|
-- worker dies between claim and send; the digest closes that gap, which
|
|
-- needs the intermediate state to be representable.
|
|
--
|
|
-- The original CHECK was defined inline in 20240101000008
|
|
-- (('sent','delivered','failed')); same drop-and-recreate pattern as the
|
|
-- notification_type constraint migrations.
|
|
|
|
ALTER TABLE public.notification_log
|
|
DROP CONSTRAINT IF EXISTS notification_log_delivery_status_check;
|
|
|
|
ALTER TABLE public.notification_log
|
|
ADD CONSTRAINT notification_log_delivery_status_check
|
|
CHECK (delivery_status IN ('pending', 'sent', 'delivered', 'failed')) NOT VALID;
|
|
|
|
ALTER TABLE public.notification_log
|
|
VALIDATE CONSTRAINT notification_log_delivery_status_check;
|
|
|
|
NOTIFY pgrst, 'reload schema';
|