Files
accounted/lib/notifications/member-email.ts
T
Mattsson 1fa34aa7ca feat(skatteverket): repair notification recipients + make the agent the SKV notification surface (#1887)
* feat(skatteverket): repair notification recipients + make the agent the SKV notification surface

The company_members -> profiles!inner(email) PostgREST embed has no FK to
traverse (company_members.user_id references auth.users), so it 400'd and
silently killed all four notification emails since they shipped. Recipient
lookup is now a shared two-step helper (lib/notifications/member-email):
kvittens confirmations, skattekonto drift alerts (tax-contact routing
preserved via the plural variant) and backup alerts deliver again. The
connection-expired email is deleted instead of fixed: with SKV's 65-minute
personal sessions it was one mail per connect (see DECISIONS.md); the event
and needs_reconsent flagging stay.

For MCP-first users the agent is the notification surface, so:
- SKATTEVERKET_NOT_CONNECTED copy is now agent-directive: session expiry is
  normal (~1h by SKV design), only a person can reconnect with BankID, do
  not retry until they confirm. Inline strings (declaration-status, read
  routes, v1 pitfalls, accounted-api skill) aligned.
- gnubok_get_agent_briefing gains an optional skatteverket_connection block
  (status/source/connected_at + directive message on needs_reconsent),
  emitted only when a connection or verified system grant exists, so agents
  warn the user at session start instead of failing mid-task. Payload bench
  ceiling bumped 59.95K -> 60.15K for the outputSchema contract.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(skatteverket): drift email resolves recipients via service client; review fixes

The skeptic pass refuted the drift-email repair: skattekonto.drift_detected
is emitted only by the nightly cron, and the extension registry builds each
event handler a fresh ctx from the anonymous cookie client (or none at all
on cookieless requests), so RLS returned zero company_members rows and the
two-step lookup still resolved no recipient. The handler now builds its own
service-role client, the same documented pattern as the retired
connection-expired handler; drift tests exercise the handler without ctx,
matching the cron reality.

CodeRabbit findings: resolveMemberEmails pages both queries through
fetchAllRows with stable ordering (PostgREST caps unpaged reads at 1000
rows); the v1 vat-declarations pitfall and regenerated accounted-api docs
now name both auth paths (member BankID connection or verified ombud
grant); the briefing's system-before-user priority carries a cross-reference
to resolveReadAuth explaining why it is not reused. member-email.ts JSDoc
states the service-role-client requirement (profiles RLS is own-row-only).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 12:09:20 +02:00

140 lines
4.8 KiB
TypeScript

/**
* Recipient resolution for notification emails.
*
* Every outbound notification restricts its recipient to active members of
* the company: a token owner, schedule owner, or configured contact who has
* since been removed must never receive company mail (the bare existence of
* some notifications is sensitive financial signal).
*
* The lookup is deliberately two queries. `company_members.user_id`
* references auth.users, not public.profiles, so the PostgREST embed
* `profiles!inner(email)` has no foreign-key relationship to traverse and
* fails the whole query with a 400. That embed shipped in four notification
* senders and silently killed all of them: the recipient resolved to null
* and every mail was skipped as "no recipient". Adding the FK instead would
* mean a migration on a core tenancy table for zero functional gain
* (see DECISIONS.md 2026-08-25).
*
* Both functions are best-effort and never throw: a failed lookup logs and
* resolves to "no recipient", because notification delivery must never fail
* the sync/cron/reconciliation that triggered it. Logging alone is not the
* safety net (the embed bug WAS logged by one caller and nobody read it):
* callers verify delivery end to end after deploy.
*
* SERVICE-ROLE CLIENT REQUIRED. Under an RLS user client these lookups
* silently degrade: company_members is readable company-wide, but the
* profiles SELECT policy is own-row-only, so resolveMemberEmails would
* return at most the caller's own email and resolveMemberEmail(other user)
* always null. Every current caller is a service-role cron path; keep it
* that way or widen the profiles policy first.
*/
import type { SupabaseClient } from '@supabase/supabase-js'
import { createLogger } from '@/lib/logger'
import { fetchAllRows } from '@/lib/supabase/fetch-all'
const log = createLogger('member-email')
/**
* Resolve one user's email, only if they are still an active member of the
* company. Returns null (never throws) when the user is not a member, has no
* profile email, or a query fails.
*/
export async function resolveMemberEmail(
supabase: SupabaseClient,
companyId: string,
userId: string
): Promise<string | null> {
const { data: member, error: memberError } = await supabase
.from('company_members')
.select('user_id')
.eq('company_id', companyId)
.eq('user_id', userId)
.maybeSingle()
if (memberError) {
log.warn('could not read company members for notification recipient', {
companyId,
userId,
error: memberError.message,
})
return null
}
if (!member) return null
const { data: profile, error: profileError } = await supabase
.from('profiles')
.select('email')
.eq('id', userId)
.maybeSingle()
if (profileError) {
log.warn('could not read profile email for notification recipient', {
companyId,
userId,
error: profileError.message,
})
return null
}
return (profile as { email?: string | null } | null)?.email ?? null
}
/**
* Resolve every active member's email for a company, as a map of
* user_id → email. Used by senders that route to a configured contact
* address but must verify it against the member allowlist (skattekonto
* drift alert). Returns an empty map (never throws) on any query failure,
* which callers treat as "no authorised recipient".
*/
export async function resolveMemberEmails(
supabase: SupabaseClient,
companyId: string
): Promise<Map<string, string>> {
const emails = new Map<string, string>()
// fetchAllRows with stable ordering: PostgREST silently caps unpaged
// reads at 1000 rows, which would drop members from the allowlist.
let members: Array<{ user_id: string | null }>
try {
members = await fetchAllRows(({ from, to }) =>
supabase
.from('company_members')
.select('user_id')
.eq('company_id', companyId)
.order('user_id', { ascending: true })
.range(from, to)
)
} catch (err) {
log.warn('could not read company members for notification allowlist', {
companyId,
error: err instanceof Error ? err.message : String(err),
})
return emails
}
const userIds = members
.map((m) => m.user_id)
.filter((id): id is string => typeof id === 'string')
if (userIds.length === 0) return emails
let profiles: Array<{ id: string; email: string | null }>
try {
profiles = await fetchAllRows(({ from, to }) =>
supabase
.from('profiles')
.select('id, email')
.in('id', userIds)
.order('id', { ascending: true })
.range(from, to)
)
} catch (err) {
log.warn('could not read member emails for notification allowlist', {
companyId,
error: err instanceof Error ? err.message : String(err),
})
return emails
}
for (const row of profiles) {
if (row.email) emails.set(row.id, row.email)
}
return emails
}