Files
accounted/lib/processing-history/append.ts
T
Mattsson 8d56219c31 fix(inbox): booked items no longer strand in Att gora as matched-forever (#1547)
* 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>
2026-08-13 00:49:20 +02:00

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
}