8d56219c31
* fix(inbox): booked items no longer strand in Att gora as matched-forever A matched inbox item only left the active inbox when created_journal_entry_id was stamped, and only categorizeTransactionCore stamped it. Booking the matched transaction through any other path (the /book dialog route, bulk-book, link-to-existing-voucher) or matching a receipt to an already-booked transaction (receipt hunt approvals, attach-document, match-transaction) left the item "linked" forever, pointing at a transaction that had already left the transactions work list. Todays hunt fix (#1524) turned this July-old gap into a visible flood of stuck items. Two-part fix, because stamps alone cannot cover the reported case: created_journal_entry_id is UNIQUE (20260515090000), so on a bulk-book samlingsverifikat only one of N matched items can ever carry it. Write side: lib/transactions/inbox-underlag.ts is the shared implementation all paths now call. It links matched items' documents to the anchoring verifikat (BFL 5 kap 6-7 kap: underlag on the verifikation) and stamps created_journal_entry_id best-effort (CAS on null, unique_violation tolerated). Wired into categorize-core (replacing its inline block), /book, bulk-book, linkTransactionToJournalEntry, both attach paths (REST + pending-operation), and the inbox match-transaction handler. The attach paths and the doc-conflict guard also resolve bulk-booked transactions through transaction_voucher_links, which they previously treated as unbooked. Read side: GET /items (and /items/:id) enrich matched-but-unstamped items with matched_transaction_journal_entry_id, and the workspace derives "booked" from it. This is what clears the stuck rows already in prod without a status backfill, and what covers the N-1 samlingsverifikat items the UNIQUE constraint refuses to stamp. Bulk-book selection filters exclude such items so "Bokfor valda" no longer offers 409 fodder. scripts/backfill-inbox-booked-underlag.ts (dry-run by default) repairs the historical document->verifikat links the old paths never made. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(inbox): stamp only settled underlag, and give the backfill behandlingshistorik Both from the Swedish accounting compliance review. The consumed-stamp is now conditional on the underlag actually referencing a verifikat: stamping over a failed document link hid the item from the .is('created_journal_entry_id', null) query forever, leaving a posted verifikation without its underlag reference (BFL 5 kap 6-7 kap) and nothing left to surface or repair it. A failed link now leaves the item unstamped so re-runs and the backfill can finish the job; a document preserved on another verifikat still counts as settled. The backfill script now appends an InboxUnderlagBackfilled event per repaired transaction to processing_history (BFNAR 2013:2 kap 8): a mass repair touching underlag-to-verifikat linkage leaves a changelog trail distinguishing it from the original booking action. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(inbox): backfill writes behandlingshistorik through the shared appender From the Swedish accounting compliance review round 2: a hand-rolled processing_history insert in the backfill script could drift from the shared row shape and skip the PII validation. appendProcessingHistory now delegates to appendProcessingHistoryWithClient, which takes a caller-supplied service-role client, so standalone scripts write behandlingshistorik through the exact same code path as the app (BFNAR 2013:2 kap 8: one reconcilable change log across writers). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(inbox): leave the item unstamped when its document belongs to another verifikat Swedish accounting review round 3: refusing to steal the document was right, but stamping the item consumed anyway hid the fact that the transaction's own verifikat ended up with no underlag reference from it (BFL 5 kap 6-7 kap). The anchored-elsewhere case now leaves created_journal_entry_id null so the mismatch keeps surfacing for reconciliation, same posture as a failed link. Also documents in the backfill script header why its writes cannot land in locked periods: linkToJournalEntry's UPDATE is guarded by the enforce_period_lock DB trigger, which fires for service-role writes too. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
208 lines
7.3 KiB
TypeScript
208 lines
7.3 KiB
TypeScript
/**
|
|
* Processing history (behandlingshistorik): append helper.
|
|
*
|
|
* Uses a service-role client internally (no INSERT RLS policy on
|
|
* processing_history: matching the event_log pattern). Company scoping
|
|
* is enforced by companyId in the event payload, not by RLS.
|
|
* Throws on failure.
|
|
*
|
|
* PII BOUNDARY: payload MUST contain pseudonymous IDs only (user UUIDs,
|
|
* company UUIDs, counterparty IDs). Never names, emails, personnummer,
|
|
* addresses, or phone numbers. These live in their source tables (profiles,
|
|
* customers, suppliers) and are referenced by ID. GDPR erasure pseudonymizes
|
|
* the source tables; processing_history events become undecipherable by
|
|
* reference, which is the required behavior per v0.2 §10.
|
|
*/
|
|
|
|
import type {
|
|
ProcessingHistoryAggregateType,
|
|
ProcessingHistoryActor,
|
|
} from '@/types'
|
|
import type { SupabaseClient } from '@supabase/supabase-js'
|
|
import { createServiceClient } from '@/lib/supabase/server'
|
|
import { z } from 'zod'
|
|
|
|
/**
|
|
* Any service-role client with the query surface the append needs. Structural
|
|
* so both the Next-bound createServiceClient() and a script's own
|
|
* createClient(url, serviceRoleKey) satisfy it.
|
|
*/
|
|
type SupabaseClientLike = Pick<SupabaseClient, 'from'>
|
|
|
|
// ── PII validator ───────────────────────────────────────────────
|
|
// Rejects payloads containing Swedish personal identity numbers.
|
|
// Personnummer: YYMMDD-NNNN or YYMMDDNNNN (6+4 digits)
|
|
// Samordningsnummer: Same format but day +60
|
|
// Organisationsnummer: NNNNNN-NNNN (10 digits, but we catch the pattern)
|
|
|
|
// Word boundaries prevent false positives on Bankgiro (123456-7890) and
|
|
// invoice references like 202312-1234 that share the digit shape but aren't PII.
|
|
const PII_PATTERNS = [
|
|
/\b\d{6}-?\d{4}\b/, // personnummer, samordningsnummer
|
|
/\b\d{8}-?\d{4}\b/, // 12-digit variant (YYYYMMDD-NNNN) or orgnr
|
|
]
|
|
|
|
// UUIDs (RFC 4122, 8-4-4-4-12 hex layout) frequently contain all-digit segments
|
|
// that incorrectly match the 8+4 personnummer pattern: e.g. `57484518-3409-...`.
|
|
// Strip UUID-shaped substrings before PII matching so legitimate identifiers
|
|
// aren't rejected. Personnummer always sit outside the UUID shape, so this keeps
|
|
// the original safety intent intact.
|
|
const UUID_PATTERN = /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/gi
|
|
|
|
function stringContainsPii(value: string): boolean {
|
|
const stripped = value.replace(UUID_PATTERN, '')
|
|
return PII_PATTERNS.some(pattern => pattern.test(stripped))
|
|
}
|
|
|
|
function containsPii(value: unknown): boolean {
|
|
if (typeof value === 'string') {
|
|
return stringContainsPii(value)
|
|
}
|
|
if (Array.isArray(value)) {
|
|
return value.some(containsPii)
|
|
}
|
|
if (value !== null && typeof value === 'object') {
|
|
return Object.values(value).some(containsPii)
|
|
}
|
|
return false
|
|
}
|
|
|
|
const piiSafePayload = z.record(z.string(), z.unknown()).refine(
|
|
(payload) => !containsPii(payload),
|
|
{ message: 'Payload contains PII (personnummer/samordningsnummer/orgnr pattern). Use pseudonymous IDs only.' }
|
|
)
|
|
|
|
function assertActorPiiSafe(actor: ProcessingHistoryActor): void {
|
|
if (actor.label && stringContainsPii(actor.label)) {
|
|
throw new Error(
|
|
'actor.label contains PII (personnummer/samordningsnummer/orgnr pattern). Use a pseudonymous descriptor only.'
|
|
)
|
|
}
|
|
}
|
|
|
|
// ── Input type ──────────────────────────────────────────────────
|
|
|
|
export interface AppendEventInput {
|
|
companyId: string
|
|
correlationId: string
|
|
causationId?: string
|
|
aggregateType: ProcessingHistoryAggregateType
|
|
aggregateId: string
|
|
eventType: string
|
|
payload: Record<string, unknown>
|
|
payloadSchemaVersion?: number
|
|
actor: ProcessingHistoryActor
|
|
rubricVersion?: string
|
|
occurredAt: Date // mandatory: no default. Caller must set explicitly.
|
|
}
|
|
|
|
// ── Append functions ────────────────────────────────────────────
|
|
|
|
/**
|
|
* Append a single event to processing_history.
|
|
*
|
|
* Uses a service-role client internally (bypasses RLS) since processing_history
|
|
* has no INSERT policy: matching the event_log pattern. Company scoping is
|
|
* enforced by the companyId in the event payload, not by RLS.
|
|
*
|
|
* Returns the generated event_id (pre-generated client-side for causation chaining).
|
|
*/
|
|
export async function appendProcessingHistory(
|
|
input: AppendEventInput
|
|
): Promise<string> {
|
|
return appendProcessingHistoryWithClient(createServiceClient(), input)
|
|
}
|
|
|
|
/**
|
|
* Same append, on a caller-supplied service-role client. For standalone
|
|
* scripts (e.g. scripts/backfill-inbox-booked-underlag.ts) that cannot build
|
|
* the Next-bound service client but must still write behandlingshistorik
|
|
* through the one shared row shape and PII validation (BFNAR 2013:2 kap 8:
|
|
* the change log has to reconcile across writers, so scripts never hand-roll
|
|
* the insert).
|
|
*/
|
|
export async function appendProcessingHistoryWithClient(
|
|
supabase: SupabaseClientLike,
|
|
input: AppendEventInput
|
|
): Promise<string> {
|
|
// Validate payload + actor.label contain no PII
|
|
piiSafePayload.parse(input.payload)
|
|
assertActorPiiSafe(input.actor)
|
|
|
|
const eventId = crypto.randomUUID()
|
|
|
|
const { error } = await supabase
|
|
.from('processing_history')
|
|
.insert({
|
|
event_id: eventId,
|
|
company_id: input.companyId,
|
|
correlation_id: input.correlationId,
|
|
causation_id: input.causationId ?? null,
|
|
aggregate_type: input.aggregateType,
|
|
aggregate_id: input.aggregateId,
|
|
event_type: input.eventType,
|
|
payload: input.payload,
|
|
payload_schema_version: input.payloadSchemaVersion ?? 1,
|
|
actor: input.actor,
|
|
rubric_version: input.rubricVersion ?? null,
|
|
occurred_at: input.occurredAt.toISOString(),
|
|
})
|
|
|
|
if (error) {
|
|
throw new Error(
|
|
`Failed to append processing_history event ${input.eventType}: ${error.message}`
|
|
)
|
|
}
|
|
|
|
return eventId
|
|
}
|
|
|
|
/**
|
|
* Append multiple events atomically (single INSERT).
|
|
* Used for batch operations (e.g., migration commits, multi-event command handlers).
|
|
*
|
|
* Returns array of generated event_ids in input order.
|
|
*/
|
|
export async function appendProcessingHistoryBatch(
|
|
inputs: AppendEventInput[]
|
|
): Promise<string[]> {
|
|
if (inputs.length === 0) return []
|
|
|
|
const eventIds = inputs.map(() => crypto.randomUUID())
|
|
|
|
// Validate all payloads + actor labels before any DB write
|
|
for (const input of inputs) {
|
|
piiSafePayload.parse(input.payload)
|
|
assertActorPiiSafe(input.actor)
|
|
}
|
|
|
|
const rows = inputs.map((input, i) => ({
|
|
event_id: eventIds[i],
|
|
company_id: input.companyId,
|
|
correlation_id: input.correlationId,
|
|
causation_id: input.causationId ?? null,
|
|
aggregate_type: input.aggregateType,
|
|
aggregate_id: input.aggregateId,
|
|
event_type: input.eventType,
|
|
payload: input.payload,
|
|
payload_schema_version: input.payloadSchemaVersion ?? 1,
|
|
actor: input.actor,
|
|
rubric_version: input.rubricVersion ?? null,
|
|
occurred_at: input.occurredAt.toISOString(),
|
|
}))
|
|
|
|
const supabase = createServiceClient()
|
|
|
|
const { error } = await supabase
|
|
.from('processing_history')
|
|
.insert(rows)
|
|
|
|
if (error) {
|
|
throw new Error(
|
|
`Failed to append processing_history batch (${inputs.length} events): ${error.message}`
|
|
)
|
|
}
|
|
|
|
return eventIds
|
|
}
|