1fa34aa7ca
* 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>
140 lines
4.8 KiB
TypeScript
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
|
|
}
|