fix(payments): lock supplier payment batch inserts to the RPC and log the raw error behind create_failed (#2282)
* fix(payments): lock supplier payment batch inserts to the RPC and log the raw error behind create_failed Two residuals from PR #1989 (atomic create_supplier_payment_batch RPC). Root cause 1: the original table migration (20260810160748) left member INSERT policies on supplier_payment_batches and supplier_payment_batch_items. The RPC is SECURITY DEFINER and never consulted them, so their only effect was to let any company member insert straight through PostgREST (browser devtools, a raw JWT call) and skip the RPC's invoice locking, in-transaction active-batch recheck and header/items totals consistency. The single write path existed in code only, not in the database. Fix 1: new migration 20260904121000 drops "insert own-company supplier_payment_batches" and "insert own-company supplier_payment_batch_items". SELECT policies on both tables and the UPDATE policy on batches (the cancel route) are untouched. No application code inserts into either table. Root cause 2: createSupplierPaymentBatch discarded the RPC error object and returned a bare create_failed, so the tenant guard (42501), a constraint violation inside the SECURITY DEFINER body and a PostgREST schema-cache miss after a deploy (PGRST202) were indistinguishable from each other and from an empty payload or an unmapped refusal code. Fix 2: log the raw error (code, message, details, hint) plus companyId, batchId and item count through lib/logger before each of the three create_failed returns. The client-facing result is unchanged; debtor_snapshot and the item rows (IBAN, payee data) are never logged. Tests: pg-real asserts the exact remaining policy set, that a member's and the owner's direct INSERT into either table is refused by RLS (42501), and that the same member still creates through the RPC and cancels through UPDATE. Unit tests assert the logger receives the raw error fields and that create_failed is still returned. Fixes #2060 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * docs(decisions): carry the ten-issue batch decision lines in one PR Append the decision lines for PRs #2272 through #2282 here so the other nine PRs in the batch do not touch DECISIONS.md and stay mergeable in any order (the union merge driver is ignored by GitHub). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * fix(payments): redact and bound raw RPC error text before logging Addresses the Superagent P2 on PR #2282 (lib/payments/batch-service.ts): message, details and hint from Postgres/PostgREST were logged verbatim, and Postgres quotes the entire failing row in details on CHECK and NOT NULL violations ("Failing row contains (..., SE45..., Anna Andersson, ...)"), so payee and account data could reach the log line. Excluding debtor_snapshot and the item rows did not cover the error text itself. Fix: a call-site helper, boundedRedactedText, runs each of the three text fields through lib/observability/redact.ts redactString (SE IBANs, personnummer, emails, API keys), drops any "Failing row contains (...)" payload whole (no pattern catches a payee name), and bounds the result to 500 chars, redaction before bounding so a cut IBAN cannot leave a digit fragment behind. The SQLSTATE code stays verbatim; the client-facing create_failed result is unchanged. Test: rejected RPC error carrying an IBAN in message, the full failing row (IBAN, payee name, account) in details and an oversized hint with the IBAN straddling the bound; asserts the serialized log context contains none of them, the row payload is replaced, and the hint is <= 500 chars ending in [TRUNCATED]. DECISIONS.md line for #2060 updated accordingly. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * fix(payments): drop the dotAll regex flag, tsconfig targets ES2017 The failing-row pattern used the `s` flag, which TypeScript rejects below es2018 (TS1501) and broke Build (zero extensions). `[\s\S]*` matches across newlines on every target. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * fix(payments): log code and message only for a failed batch RPC Reworks the logging half of #2060 from first principles. The diagnostic value of a failed create_supplier_payment_batch call lies in the SQLSTATE code and the message: the RPC's own RAISE text, "violates check constraint <name>", "duplicate key value violates unique constraint <name>". details is exactly where Postgres puts row data ("Failing row contains (...)", "Key (...)=(...)") and hint adds nothing operational, so neither is logged at all. That removes the payee/account exposure Superagent flagged on #2282 without the bespoke redact-and-bound helper, its regex and the TS-target workaround it needed: boundedRedactedText, FAILING_ROW_PATTERN, RPC_ERROR_TEXT_MAX and TRUNCATED are deleted, and the redact import goes with them. The logger's own redaction stays as the safety net for message. Client-facing result unchanged (create_failed). Test: an RPC error carrying an IBAN and a payee name in details and hint; the serialized log context contains neither field in any shape, and rpcError is exactly { code, message }. Exact-match and PGRST202 tests updated to the two-field shape. DECISIONS.md line for #2060 rewritten. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * docs(decisions): record the first-principles rework of the ten-issue batch Replace the decision lines for #2263, #2250, #2256 and #2211 with the reworked shapes, add the shared customer-share definition for #2248, and note the CLAUDE.md principle (#2283) that drove the rework. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * docs(decisions): note the fiscal-year selection cap on #2280 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u --------- Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Jakob Wennberg
@@ -1568,4 +1568,17 @@ One line per decision: `[YYYY-MM-DD] <decision>: <why>`. Appended by agents and
|
||||
[2026-09-03] Per-invoice payee migrations re-issued as 20260904010000 and 20260904011000 (were 20260903150000 / 20260903193000, merged in #2233 but never applied): the backfill's INSERT into invoice_payee_defaults fired the mirror into company_settings for a company that is a migration-reset source, whose rows are immutable by trigger, so the whole migration rolled back on prod and every later migration queued behind it. Same pattern as #2249: skip company_migration_resets sources in the backfill and re-issue under a fresh version rather than edit the failed file in place, so any environment that did apply the old version (staging, by hand) is reconciled by renaming its schema_migrations row instead of diverging silently.
|
||||
[2026-09-04] ROT/RUT payout matching models the begäran (rot_rut_payout_requests), not the invoice, as the bank-row match candidate: Skatteverket pays one lump sum per begäran covering several invoices, remaining_amount is net of the deduction so a paid ROT/RUT invoice can never match, and 1513 clears per request. Confirm reuses the settle service with the transaction linked in the same call; its own dialog (RotRutPayoutMatchDialog) rather than a third branch in InvoiceMatchDialog, which carries FX/preview/edit logic this two-leg entry never needs.
|
||||
[2026-09-04] Parties name extraction is rule-based first (legal-form and country anchors in lib/parties/name-extract.ts), no LLM in the batch: every candidate is a substring of the voucher text, testable and free; an AI read for the leftovers (bank memos with no anchor) waits for the founder's call on automatic vs on-click. The picker makes no SCB call when the best reading is a foreign company: the register holds Swedish legal persons only, so a search there can only mislead.
|
||||
[2026-09-04] Decision lines for the ten-issue batch (PRs #2272 #2273 #2275 #2276 #2277 #2278 #2279 #2280 #2281 #2282) are carried in PR #2282 alone: DECISIONS.md is append-only and the union merge driver is ignored by GitHub, so one carrier keeps the other nine PRs mergeable in any order.
|
||||
[2026-09-04] "Fix From First Principles" added to CLAUDE.md (#2283) after the ten-issue batch and applied to it retroactively: six of ten PRs changed shape (a counter removed instead of made filter-aware, a CHECK constraint instead of a trigger, one invoice_payments writer plus a guard instead of a shared amount helper, one customer-share definition instead of a fourth copy, code + message logging instead of redacted free text, a fiscal-year picker instead of an explained cap); the other four kept their shape with the alternative recorded in the PR body.
|
||||
[2026-09-04] Självfaktura (#2264): the self_billing.received_date_* keys were renamed in place ("Mottaget datum" to "Ankomstdatum", en "Date received") plus a help text, and the footer hint invoice_editor.next_step_received_date follows: the keys are used only by InvoiceEditor's self-billed branch and the supplier-invoice form has its own column and wording, so nothing shared needed a new key.
|
||||
[2026-09-04] Kontoplan per-class band counter removed rather than re-derived under filters (#2263, fix from first principles): it was computed from the already-filtered class group, the reporter asked for it to go, the issue offered removal, and nothing consumed it; the tab chip and the footer "Visar N av M konton" remain the page's only counts, and a counter that does not exist cannot drift the next time a filter is added.
|
||||
[2026-09-04] /mfa/verify (#2056) hard-navigates with window.location.assign on the default path, collapsing the /api/ returnTo branch; the invite-problem toast on that path is now lost to the page load, the same trade-off accepted in #1984 and the 2026-07-26 invite-cookie entry, and the invite path keeps its own window.location.href = '/' because it ignores returnTo.
|
||||
[2026-09-04] Arcim registration-link row (#2045): alreadyLinked is counted into the displayed total rather than shown as a separate row, because the lib buckets it as a terminal "done" outcome (a subset of scanned); the already-linked sentence is joined into the existing single detail paragraph instead of widening entityLines.detail to string[].
|
||||
[2026-09-04] #2250 fixed from first principles: recordInvoicePaymentRow() is the single writer of invoice_payments rows (options widened with transactionId/exchangeRate/notes, defaults unchanged for #2236 callers) and check:guards refuses direct inserts outside it (rule direct-invoice-payment-insert): the bug was five hand-built inserts with no shared row definition, so a shared amount helper alone would have fixed the instance and left the class; routing the four remaining writers through the helper and guarding it makes "every row means the same thing" a CI property instead of a convention. link-journal-entry.ts was routed too rather than allowlisted (strict plan, amount unchanged).
|
||||
[2026-09-04] Kontantmetod cut-off (#2248) measures a customer invoice's outstanding as total - deduction_total - paid, floored at zero on the invoice's own side for ROT/RUT rows only, and scales the cut-off moms by the customer share: the deduction is Skatteverket's fordran on 1513 booked by the payment voucher itself and every settlement path records the customer share as the payment row amount, so the gross comparison booked a phantom 1510 fordran with phantom 2618 on fully paid ROT/RUT invoices. Plain invoices keep the byte-identical gross path. The 1513 share of an unpaid ROT/RUT invoice is deliberately not booked by the cut-off (the Skatteverket fordran stays an own change, alongside the 1513 point deferred on the currency revaluation 2026-07-29).
|
||||
[2026-09-04] #2248 fixed from first principles, not by patching the cut-off's arithmetic: the customer share of an invoice (total minus sign(total) times deduction_total, and the signed residual after payments) now has one definition in lib/invoices/customer-share.ts (invoiceCustomerShare / invoiceCustomerOutstanding) with the SQL guard 20260817191708 named as its twin, used by the kontantmetod cut-off, rot-rut-file and payment-sync; the cut-off's copy was the second drift of the same hand-rolled expression (payment-sync drifted 2026-08-25), so a fourth copy would have invited a third. The shared value is unfloored on purpose: the guard floors because it persists the column, payment-sync mirrors it with Math.max(0, ...), and the cut-off floors sign-aware for ROT/RUT rows so credit notes keep their sign; plain invoices get their total back exactly as stored so those paths are byte-identical. Other deduction_total readers with their own semantics (invoice-entries invoiceOutstandingAmount, rounding.ts getAmountToPay, mark-paid settlement cap) were left for a per-site follow-up.
|
||||
[2026-09-04] Jamkning both-dates invariant enforced as CHECK constraint employees_jamkning_dates_check NOT VALID, not the trigger #2256 proposed (fix from first principles): a row-level fact belongs on the row; the trigger existed only to spare legacy incomplete rows unrelated edits and cost a plpgsql function, per-column change detection and a custom message convention. Trade-off accepted: legacy rows must be completed or cleared on their next edit (mapped to the validator's Swedish sentence). The constraint checks date ordering even when the percentage is null, mirroring validateJamkning and the Zod update schema exactly. jamkningIssueFromDbError derives the sentence from the merged row and falls back to an umbrella sentence: a CHECK violation cannot say which clause failed, and PostgREST exposes the constraint name only inside message (details carries the failing row and is never forwarded).
|
||||
[2026-09-04] Supplier payment batches (#2060, migration 20260904121000): the two member INSERT policies are dropped because the SECURITY DEFINER RPC is the only write path; a failed RPC logs only the SQLSTATE code and the message, nested under one rpcError ctx key so the SQLSTATE is never confused with the RPC's own domain refusal code (rpcCode) that the unmapped branch logs; details and hint are never logged. First principles: the diagnostic value lives in code + message (the RPC's RAISE text, "violates check constraint <name>", "duplicate key value violates unique constraint <name>"), while details is exactly where Postgres quotes row data ("Failing row contains (...)", "Key (...)=(...)") and hint adds nothing operational, so not logging them removes the payee/account exposure the Superagent P2 on #2282 flagged with no bespoke redact-and-bound helper (an earlier revision of this PR carried one, plus a regex and a TS-target workaround; deleted). The logger's own redaction stays as the safety net for message. The pg tests cover a plain member as well as the owner (the least-privileged writer that must still succeed via the RPC). The pre-existing anon EXECUTE assertion failing under tool-pg is the reset.sh blanket-grant artifact, not fixed.
|
||||
[2026-09-04] Fortnox/provider migration (#2211, #2238, fix from first principles): the three-year fiscal-year window (getAllowedFiscalYears, #718) became a DEFAULT selection with a year picker, not a fixed lift to every year: the window gates only the SIE fetch (documents, invoices, assets never were), the import is one request per year (300 s function, 290 s RPC) so its cost is bounded per year, but /preview and /sie-data fetch and parse one SIE export per selected year inside a single 300 s invocation (15 s timeout, 3 attempts, 30 s backoff) and no Fortnox export latency is measured in the repo; a selection keeps the default cost identical and an oversized selection fails in /sie-data before any ledger write. Explaining the cap and pointing at SIE (the first version of #2280) was replaced, not kept: the user's problem was a missing year with its documents, and the SIE path leaves document re-attachment as manual work, which is what the import exists to remove. Source years are keyed by start year in the selection (years=2022,2024), consistent with fileStatuses.fiscalYear; two fiscal years starting in the same calendar year already collide in the existing import and were not fixed here. Splitting /sie-data into per-year requests is a restructure (the mapping step needs the account union across files), deferred until large selections time out in practice. The selection per run is capped at MAX_SELECTED_FISCAL_YEARS = 6, derived from the /sie-data budget (300 s function; 48 s worst case per year = 3 x 15 s timeout + 1 s + 2 s backoff; 6 x 48 = 288 s), enforced in the route before the consent is resolved and mirrored in the picker via /preview rather than a client-side constant; unknown years are refused after the year listing and before the first export (Superagent P2 on #2280). Lifting the cap means per-year /sie-data requests, a restructure, not a bigger number.
|
||||
[2026-09-04] Supplier-invoice list overflow (#2262) fixed per page, not in a shared list component: none exists (every list hand-writes the overflow-x-auto wrapper) and the three overflow reports had three different causes, so the column budget went into .claude/rules/design.md instead. Fakturadatum was dropped rather than Kvar or the action column (förfaller is the payer's date and the default order, the customer list has no invoice-date column either); the always-visible sort icon from #2091 was kept although it was the proximate regression.
|
||||
[2026-09-04] Parties: the model reads a counterpart only on demand (picker, review list), never when the queue builds: a five-hundred-row queue would cost five hundred calls nobody asked for and a rebuild would repeat them; the reading is a 'model' fact and a search query, never a hard key. The review list ticks rows with exactly one active SCB match but writes nothing until a person approves: an exact legal name plus one active hit is high precision, auto-attaching would still be the system choosing. Exact legal-form names ("Visma Spcs AB", not "Visma") group keys and attach to existing parties: registered company names are unique in Sweden, so this is a key in all but form; the "name never merges" rule keeps applying to fuzzy and form-less names.
|
||||
|
||||
@@ -1,4 +1,22 @@
|
||||
import { beforeEach, describe, expect, it, vi } from 'vitest'
|
||||
|
||||
// #2060: the diagnostic behind create_failed is a log line, so the logger is
|
||||
// the assertion surface. The REAL logger module is kept and only `error` is
|
||||
// swapped (same shape as lib/reconciliation/__tests__/bank-reconciliation.test.ts):
|
||||
// a file-global stub would throw from any module in this file's graph that
|
||||
// calls a level the stub omitted.
|
||||
const { logError } = vi.hoisted(() => ({ logError: vi.fn() }))
|
||||
vi.mock('@/lib/logger', async (importOriginal) => {
|
||||
const actual = await importOriginal<typeof import('@/lib/logger')>()
|
||||
return {
|
||||
...actual,
|
||||
createLogger: (module: string, base?: Parameters<typeof actual.createLogger>[1]) => ({
|
||||
...actual.createLogger(module, base),
|
||||
error: logError,
|
||||
}),
|
||||
}
|
||||
})
|
||||
|
||||
import type { SupabaseClient } from '@supabase/supabase-js'
|
||||
import { eventBus } from '@/lib/events'
|
||||
import { createQueuedMockSupabase } from '@/tests/helpers'
|
||||
@@ -11,6 +29,7 @@ import type { SupplierPaymentBatch, SupplierPaymentBatchItem } from '@/types'
|
||||
|
||||
const COMPANY_ID = 'c0000000-0000-0000-0000-000000000001'
|
||||
const USER_ID = 'u0000000-0000-0000-0000-000000000001'
|
||||
const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/
|
||||
|
||||
const companyRow = { name: 'Testbolaget AB', org_number: '556677-8899' }
|
||||
const settingsRow = {
|
||||
@@ -322,14 +341,106 @@ describe('createSupplierPaymentBatch', () => {
|
||||
})
|
||||
})
|
||||
|
||||
it('maps an RPC error (constraint violation, guard) to create_failed', async () => {
|
||||
it('maps an RPC error (constraint violation, guard) to create_failed and logs the raw error', async () => {
|
||||
const mock = createQueuedMockSupabase()
|
||||
const rpcError = {
|
||||
code: '23514',
|
||||
message:
|
||||
'new row for relation "supplier_payment_batch_items" violates check constraint "supplier_payment_batch_items_payee_fields_match"',
|
||||
details: 'Failing row contains (...).',
|
||||
hint: null,
|
||||
}
|
||||
mock.enqueueMany([
|
||||
{ data: companyRow },
|
||||
{ data: settingsRow },
|
||||
{ data: [invoiceRow()] },
|
||||
{ data: [] },
|
||||
{ error: { message: 'payee_fields_match', code: '23514' } },
|
||||
{ error: rpcError },
|
||||
])
|
||||
|
||||
const result = await createSupplierPaymentBatch(
|
||||
mock.supabase as unknown as SupabaseClient,
|
||||
COMPANY_ID,
|
||||
USER_ID,
|
||||
{ format: 'pain001', items: [{ supplier_invoice_id: 'inv-1' }] },
|
||||
)
|
||||
|
||||
// The client contract is unchanged: a generic create_failed, nothing else.
|
||||
expect(result).toEqual({ ok: false, code: 'create_failed' })
|
||||
|
||||
// The diagnosis lives in the log (#2060): SQLSTATE and message only, keyed
|
||||
// by company, batch and item count. Exact match on purpose: details and
|
||||
// hint (where Postgres quotes row data), the debtor snapshot and the item
|
||||
// rows must never ride along.
|
||||
expect(logError).toHaveBeenCalledTimes(1)
|
||||
expect(logError).toHaveBeenCalledWith('create_supplier_payment_batch RPC failed', {
|
||||
companyId: COMPANY_ID,
|
||||
batchId: expect.stringMatching(UUID_RE),
|
||||
itemCount: 1,
|
||||
rpcError: { code: '23514', message: rpcError.message },
|
||||
})
|
||||
const [, ctx] = logError.mock.calls[0] as [string, Record<string, unknown>]
|
||||
expect(ctx.batchId).toBe((mock.supabase.rpc.mock.calls[0][1] as { p_batch_id: string }).p_batch_id)
|
||||
})
|
||||
|
||||
it('never logs details or hint: an IBAN and a payee name there cannot reach the log, code and message do', async () => {
|
||||
const mock = createQueuedMockSupabase()
|
||||
const IBAN = 'SE4550000000058398257466'
|
||||
const rpcError = {
|
||||
code: '23514',
|
||||
message:
|
||||
'new row for relation "supplier_payment_batch_items" violates check constraint "supplier_payment_batch_items_payee_fields_match"',
|
||||
// Where Postgres quotes the entire failing row (payee name, account).
|
||||
details:
|
||||
'Failing row contains (b0000000-0000-0000-0000-000000000001, c0000000-0000-0000-0000-000000000001, ' +
|
||||
`737.50, 2099-08-15, bank_account, null, null, 5000, ${IBAN}, Anna Andersson, invoice_number, CD3014794407).`,
|
||||
hint: `Check the payee fields for Anna Andersson (${IBAN}).`,
|
||||
}
|
||||
mock.enqueueMany([
|
||||
{ data: companyRow },
|
||||
{ data: settingsRow },
|
||||
{ data: [invoiceRow()] },
|
||||
{ data: [] },
|
||||
{ error: rpcError },
|
||||
])
|
||||
|
||||
const result = await createSupplierPaymentBatch(
|
||||
mock.supabase as unknown as SupabaseClient,
|
||||
COMPANY_ID,
|
||||
USER_ID,
|
||||
{ format: 'pain001', items: [{ supplier_invoice_id: 'inv-1' }] },
|
||||
)
|
||||
expect(result).toEqual({ ok: false, code: 'create_failed' })
|
||||
|
||||
expect(logError).toHaveBeenCalledTimes(1)
|
||||
const [, ctx] = logError.mock.calls[0] as [string, Record<string, unknown>]
|
||||
// Nothing from details or hint, in any shape, anywhere in the context.
|
||||
const serialized = JSON.stringify(ctx)
|
||||
expect(serialized).not.toContain(IBAN)
|
||||
expect(serialized).not.toContain('Anna Andersson')
|
||||
expect(serialized).not.toContain('Failing row')
|
||||
expect(serialized).not.toContain(rpcError.hint)
|
||||
expect(ctx).not.toHaveProperty(['rpcError', 'details'])
|
||||
expect(ctx).not.toHaveProperty(['rpcError', 'hint'])
|
||||
// Only the two fields with diagnostic value, verbatim.
|
||||
expect(ctx.rpcError).toEqual({ code: '23514', message: rpcError.message })
|
||||
})
|
||||
|
||||
it('logs a PostgREST schema-cache miss (PGRST202) the same way, still as create_failed', async () => {
|
||||
const mock = createQueuedMockSupabase()
|
||||
const rpcError = {
|
||||
code: 'PGRST202',
|
||||
message:
|
||||
'Could not find the function public.create_supplier_payment_batch(p_batch_id, ...) in the schema cache',
|
||||
details: 'Searched for the function public.create_supplier_payment_batch with parameters ...',
|
||||
hint: 'Perhaps you meant to call the function public.create_supplier_payment_batch without parameters',
|
||||
}
|
||||
mock.enqueueMany([
|
||||
{ data: companyRow },
|
||||
{ data: settingsRow },
|
||||
{ data: [invoiceRow()] },
|
||||
{ data: [] },
|
||||
{ error: rpcError },
|
||||
])
|
||||
|
||||
const result = await createSupplierPaymentBatch(
|
||||
@@ -340,6 +451,14 @@ describe('createSupplierPaymentBatch', () => {
|
||||
)
|
||||
|
||||
expect(result).toEqual({ ok: false, code: 'create_failed' })
|
||||
expect(logError).toHaveBeenCalledWith(
|
||||
'create_supplier_payment_batch RPC failed',
|
||||
expect.objectContaining({
|
||||
companyId: COMPANY_ID,
|
||||
itemCount: 1,
|
||||
rpcError: { code: 'PGRST202', message: rpcError.message },
|
||||
}),
|
||||
)
|
||||
})
|
||||
|
||||
it('maps an unknown RPC refusal code and an empty RPC payload to create_failed', async () => {
|
||||
@@ -365,6 +484,19 @@ describe('createSupplierPaymentBatch', () => {
|
||||
input,
|
||||
)
|
||||
expect(unknown).toEqual({ ok: false, code: 'create_failed' })
|
||||
// An unmapped refusal code is logged with the code itself, so a code added
|
||||
// in SQL without a client mapping cannot vanish behind create_failed.
|
||||
expect(logError).toHaveBeenCalledTimes(1)
|
||||
expect(logError).toHaveBeenLastCalledWith(
|
||||
'create_supplier_payment_batch RPC refused with an unmapped code',
|
||||
{
|
||||
companyId: COMPANY_ID,
|
||||
batchId: expect.stringMatching(UUID_RE),
|
||||
itemCount: 1,
|
||||
rpcCode: 'something_new',
|
||||
rpcDetails: undefined,
|
||||
},
|
||||
)
|
||||
|
||||
const empty = await createSupplierPaymentBatch(
|
||||
mock.supabase as unknown as SupabaseClient,
|
||||
@@ -373,6 +505,44 @@ describe('createSupplierPaymentBatch', () => {
|
||||
input,
|
||||
)
|
||||
expect(empty).toEqual({ ok: false, code: 'create_failed' })
|
||||
expect(logError).toHaveBeenCalledTimes(2)
|
||||
expect(logError).toHaveBeenLastCalledWith(
|
||||
'create_supplier_payment_batch RPC returned no payload',
|
||||
{ companyId: COMPANY_ID, batchId: expect.stringMatching(UUID_RE), itemCount: 1 },
|
||||
)
|
||||
})
|
||||
|
||||
it('does not log when the RPC succeeds or refuses with a mapped code', async () => {
|
||||
const mock = createQueuedMockSupabase()
|
||||
mock.enqueueMany([
|
||||
{ data: companyRow },
|
||||
{ data: settingsRow },
|
||||
{ data: [invoiceRow()] },
|
||||
{ data: [] },
|
||||
{ data: { ok: true, batch: batchRow() } },
|
||||
{ data: companyRow },
|
||||
{ data: settingsRow },
|
||||
{ data: [invoiceRow()] },
|
||||
{ data: [] },
|
||||
{ data: { ok: false, code: 'already_batched', details: [{ id: 'inv-1', batch_id: 'b' }] } },
|
||||
])
|
||||
const input = { format: 'pain001' as const, items: [{ supplier_invoice_id: 'inv-1' }] }
|
||||
|
||||
const created = await createSupplierPaymentBatch(
|
||||
mock.supabase as unknown as SupabaseClient,
|
||||
COMPANY_ID,
|
||||
USER_ID,
|
||||
input,
|
||||
)
|
||||
expect(created.ok).toBe(true)
|
||||
const refused = await createSupplierPaymentBatch(
|
||||
mock.supabase as unknown as SupabaseClient,
|
||||
COMPANY_ID,
|
||||
USER_ID,
|
||||
input,
|
||||
)
|
||||
expect(refused).toMatchObject({ ok: false, code: 'already_batched' })
|
||||
expect(logError).not.toHaveBeenCalled()
|
||||
})
|
||||
|
||||
it('rejects the whole batch when any invoice is ineligible', async () => {
|
||||
|
||||
@@ -20,6 +20,7 @@
|
||||
*/
|
||||
|
||||
import type { SupabaseClient } from '@supabase/supabase-js'
|
||||
import { createLogger } from '@/lib/logger'
|
||||
import { getBranding } from '@/lib/branding/service'
|
||||
import { getSwedishLocalDate } from '@/lib/bookkeeping/engine'
|
||||
import { ORE_TOLERANCE, roundOre, sumOre } from '@/lib/money'
|
||||
@@ -39,6 +40,8 @@ import { formatPayeeLabel, type SupplierPayeeSource } from './supplier-payee'
|
||||
import { generateSupplierPain001, type SupplierPain001Payment } from './pain001-supplier'
|
||||
import type { SupplierPaymentBatch, SupplierPaymentBatchItem } from '@/types'
|
||||
|
||||
const log = createLogger('payments/batch-service')
|
||||
|
||||
type InvoiceRow = BatchInvoiceFacts & {
|
||||
supplier: (SupplierPayeeSource & { id: string; name: string; city: string | null }) | null
|
||||
}
|
||||
@@ -363,10 +366,36 @@ export async function createSupplierPaymentBatch(
|
||||
p_confirm_already_batched: input.confirm_already_batched ?? false,
|
||||
p_user_id: userId,
|
||||
})
|
||||
if (error) return { ok: false, code: 'create_failed' }
|
||||
// The client only ever sees create_failed. What tells the RPC's tenant
|
||||
// guard (42501), a constraint violation inside the SECURITY DEFINER body
|
||||
// and a PostgREST schema-cache miss right after a deploy (PGRST202) apart
|
||||
// is the SQLSTATE plus the message (the RPC's own RAISE text, "violates
|
||||
// check constraint <name>", "duplicate key value violates unique
|
||||
// constraint <name>"), so those two go to the log (#2060). `details` is
|
||||
// where Postgres quotes row data ("Failing row contains (...)",
|
||||
// "Key (...)=(...)") and `hint` adds nothing operational: neither is
|
||||
// logged, so payee and account data cannot reach a log line through them.
|
||||
// debtor_snapshot and the item rows are not logged either; companyId,
|
||||
// batchId and the item count make the line greppable.
|
||||
if (error) {
|
||||
log.error('create_supplier_payment_batch RPC failed', {
|
||||
companyId,
|
||||
batchId,
|
||||
itemCount: itemRows.length,
|
||||
rpcError: { code: error.code, message: error.message },
|
||||
})
|
||||
return { ok: false, code: 'create_failed' }
|
||||
}
|
||||
|
||||
const result = data as CreateBatchRpcResult | null
|
||||
if (!result) return { ok: false, code: 'create_failed' }
|
||||
if (!result) {
|
||||
log.error('create_supplier_payment_batch RPC returned no payload', {
|
||||
companyId,
|
||||
batchId,
|
||||
itemCount: itemRows.length,
|
||||
})
|
||||
return { ok: false, code: 'create_failed' }
|
||||
}
|
||||
if (!result.ok) {
|
||||
switch (result.code) {
|
||||
case 'already_batched':
|
||||
@@ -388,6 +417,16 @@ export async function createSupplierPaymentBatch(
|
||||
details: result.details as Array<{ id: string; reason: string }>,
|
||||
}
|
||||
default:
|
||||
// An RPC refusal code with no client mapping (a code added in SQL
|
||||
// without this switch learning it, or the RPC's own payload-shape
|
||||
// refusals) must stay visible rather than vanish behind create_failed.
|
||||
log.error('create_supplier_payment_batch RPC refused with an unmapped code', {
|
||||
companyId,
|
||||
batchId,
|
||||
itemCount: itemRows.length,
|
||||
rpcCode: result.code,
|
||||
rpcDetails: result.details,
|
||||
})
|
||||
return { ok: false, code: 'create_failed' }
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
-- Lock supplier payment batch INSERTs to the RPC (#2060, residual from #1989).
|
||||
-- pg-test: tests/pg/supplier-payment-batches.pg.test.ts
|
||||
--
|
||||
-- create_supplier_payment_batch (20260827100000) is SECURITY DEFINER and the
|
||||
-- only legitimate writer of supplier_payment_batches and
|
||||
-- supplier_payment_batch_items: it locks the selected invoices FOR UPDATE,
|
||||
-- rechecks active batches inside the transaction, computes the header totals
|
||||
-- from the items, and inserts header + items atomically. SECURITY DEFINER
|
||||
-- bypasses RLS, so the RPC never consulted the two INSERT policies below.
|
||||
-- Their only effect was to let any company member INSERT straight through
|
||||
-- PostgREST (browser devtools, a raw JWT call) and skip every one of those
|
||||
-- checks: a header whose total_amount / item_count disagree with its rows, or
|
||||
-- a second active batch for an invoice already sitting in one, both of which
|
||||
-- the RPC exists to prevent. The write path was single in code only, not in
|
||||
-- the database.
|
||||
--
|
||||
-- No application code inserts into either table: every
|
||||
-- .from('supplier_payment_batches') / .from('supplier_payment_batch_items')
|
||||
-- in app/, lib/, extensions/ and scripts/ is a SELECT or an UPDATE, and
|
||||
-- service-role paths bypass RLS regardless. Kept untouched: the SELECT
|
||||
-- policies on both tables and the UPDATE policy on batches (the cancel
|
||||
-- route's created -> cancelled transition, column-guarded by
|
||||
-- enforce_supplier_payment_batch_immutability). Items keep no UPDATE/DELETE
|
||||
-- policy, as before: they are immutable snapshots.
|
||||
--
|
||||
-- Policy-only change, no table structure change, so no schema reload.
|
||||
|
||||
DROP POLICY IF EXISTS "insert own-company supplier_payment_batches"
|
||||
ON public.supplier_payment_batches;
|
||||
DROP POLICY IF EXISTS "insert own-company supplier_payment_batch_items"
|
||||
ON public.supplier_payment_batch_items;
|
||||
@@ -2,7 +2,7 @@ import { randomUUID } from 'node:crypto'
|
||||
import type { PoolClient } from 'pg'
|
||||
import { describe, expect, it } from 'vitest'
|
||||
import { getClient, getPool, withUserContext } from './setup'
|
||||
import { seedCompany, insertAuthUser } from './fixtures'
|
||||
import { seedCompany, insertAuthUser, insertCompanyMember } from './fixtures'
|
||||
|
||||
// pg-real coverage for 20260810160748_supplier_payment_batches.sql: RLS
|
||||
// isolation on both tables, the FK RESTRICT that keeps invoices referenced by
|
||||
@@ -14,6 +14,16 @@ import { seedCompany, insertAuthUser } from './fixtures'
|
||||
// the atomic create RPC (happy path, in-transaction active-batch recheck,
|
||||
// header + items rolling back together, FOR UPDATE serialization of two
|
||||
// concurrent creates, tenant guard and actor pinning, EXECUTE privileges).
|
||||
//
|
||||
// And 20260904121000_supplier_payment_batches_drop_insert_policies.sql
|
||||
// (#2060): the member INSERT policies on both tables are gone, so the
|
||||
// SECURITY DEFINER RPC is the only write path in the database as well as in
|
||||
// code, while SELECT (both tables) and the batches UPDATE (cancel) stay.
|
||||
//
|
||||
// Every fixture that seeds a batch or an item directly (insertBatch,
|
||||
// insertItem, seedBatchWithItem) runs on the plain pool, i.e. the superuser
|
||||
// connection outside withUserContext, so none of them ever relied on the
|
||||
// dropped INSERT policies.
|
||||
|
||||
async function insertSupplier(companyId: string, userId: string): Promise<string> {
|
||||
const id = randomUUID()
|
||||
@@ -683,3 +693,154 @@ describe('create_supplier_payment_batch RPC', () => {
|
||||
expect(rows[0]).toEqual({ anon_can: false, authenticated_can: true, service_role_can: true })
|
||||
})
|
||||
})
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// INSERT locked to the RPC (#2060)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
/** A plain 'member' (not the owner seedCompany creates): the least-privileged
|
||||
* role the RPC still accepts as a writer. */
|
||||
async function seedMember(companyId: string): Promise<string> {
|
||||
const userId = await insertAuthUser()
|
||||
await insertCompanyMember({ companyId, userId, role: 'member' })
|
||||
return userId
|
||||
}
|
||||
|
||||
async function captureError(
|
||||
run: () => Promise<unknown>,
|
||||
): Promise<{ code?: string; message?: string } | null> {
|
||||
try {
|
||||
await run()
|
||||
return null
|
||||
} catch (err) {
|
||||
return err as { code?: string; message?: string }
|
||||
}
|
||||
}
|
||||
|
||||
const DIRECT_BATCH_INSERT = `
|
||||
INSERT INTO public.supplier_payment_batches
|
||||
(id, company_id, user_id, format, total_amount, item_count, msg_id, debtor_snapshot)
|
||||
VALUES ($1, $2, $3, 'pain001', 737.5, 1, 'X', '{}')`
|
||||
|
||||
const DIRECT_ITEM_INSERT = `
|
||||
INSERT INTO public.supplier_payment_batch_items
|
||||
(batch_id, company_id, supplier_invoice_id, amount, payment_date,
|
||||
payee_type, payee_bankgiro, payee_name, reference_type, reference)
|
||||
VALUES ($1, $2, $3, 737.5, '2099-08-15', 'bankgiro', '50501055',
|
||||
'Derome Bygg AB', 'invoice_number', 'CD3014794407')`
|
||||
|
||||
describe('supplier_payment_batches: INSERT locked to the RPC (#2060)', () => {
|
||||
it('leaves exactly the SELECT policies and the batches UPDATE policy in the catalog', async () => {
|
||||
const { rows } = await getPool().query<{
|
||||
tablename: string
|
||||
policyname: string
|
||||
cmd: string
|
||||
}>(
|
||||
`SELECT tablename, policyname, cmd
|
||||
FROM pg_policies
|
||||
WHERE schemaname = 'public'
|
||||
AND tablename IN ('supplier_payment_batches', 'supplier_payment_batch_items')
|
||||
ORDER BY tablename, cmd, policyname`,
|
||||
)
|
||||
expect(rows).toEqual([
|
||||
{
|
||||
tablename: 'supplier_payment_batch_items',
|
||||
policyname: 'view own-company supplier_payment_batch_items',
|
||||
cmd: 'SELECT',
|
||||
},
|
||||
{
|
||||
tablename: 'supplier_payment_batches',
|
||||
policyname: 'view own-company supplier_payment_batches',
|
||||
cmd: 'SELECT',
|
||||
},
|
||||
{
|
||||
tablename: 'supplier_payment_batches',
|
||||
policyname: 'update own-company supplier_payment_batches',
|
||||
cmd: 'UPDATE',
|
||||
},
|
||||
])
|
||||
})
|
||||
|
||||
it('refuses a direct INSERT into supplier_payment_batches from a member and from the owner', async () => {
|
||||
const ctx = await seedCompany()
|
||||
const memberId = await seedMember(ctx.companyId)
|
||||
|
||||
for (const userId of [memberId, ctx.userId]) {
|
||||
const err = await captureError(() =>
|
||||
withUserContext(userId, (client) =>
|
||||
client.query(DIRECT_BATCH_INSERT, [randomUUID(), ctx.companyId, userId]),
|
||||
),
|
||||
)
|
||||
expect(err?.code).toBe('42501')
|
||||
expect(err?.message).toMatch(/row-level security/)
|
||||
}
|
||||
})
|
||||
|
||||
it('refuses a direct INSERT into supplier_payment_batch_items from a member and from the owner', async () => {
|
||||
// The batch itself is seeded on the superuser pool; only the item insert
|
||||
// runs under the member's JWT.
|
||||
const ctx = await seedBatchWithItem()
|
||||
const memberId = await seedMember(ctx.companyId)
|
||||
const otherInvoice = await insertSupplierInvoice(ctx.companyId, ctx.userId, ctx.supplierId)
|
||||
|
||||
for (const userId of [memberId, ctx.userId]) {
|
||||
const err = await captureError(() =>
|
||||
withUserContext(userId, (client) =>
|
||||
client.query(DIRECT_ITEM_INSERT, [ctx.batchId, ctx.companyId, otherInvoice]),
|
||||
),
|
||||
)
|
||||
expect(err?.code).toBe('42501')
|
||||
expect(err?.message).toMatch(/row-level security/)
|
||||
}
|
||||
expect(await countItems(null, ctx.batchId)).toBe(1)
|
||||
})
|
||||
|
||||
it('still creates through the RPC and cancels through UPDATE for the member whose direct INSERT was refused', async () => {
|
||||
const ctx = await seedInvoiceOnly()
|
||||
const memberId = await seedMember(ctx.companyId)
|
||||
const batchId = randomUUID()
|
||||
|
||||
const outcome = await withUserContext(memberId, async (client) => {
|
||||
// Same session, same authenticated role: the direct write is refused...
|
||||
await client.query('SAVEPOINT direct_insert')
|
||||
const direct = await captureError(() =>
|
||||
client.query(DIRECT_BATCH_INSERT, [batchId, ctx.companyId, memberId]),
|
||||
)
|
||||
await client.query('ROLLBACK TO SAVEPOINT direct_insert')
|
||||
|
||||
// ...while the SECURITY DEFINER RPC, which never consulted the dropped
|
||||
// policies, still lands header + items for the same caller.
|
||||
const result = await callRpc(client, {
|
||||
companyId: ctx.companyId,
|
||||
batchId,
|
||||
items: itemsPayload(ctx.invoiceId),
|
||||
})
|
||||
const items = await countItems(client, batchId)
|
||||
|
||||
// The kept UPDATE policy: the member cancels the batch the RPC created
|
||||
// (the cancel route's compare-and-set), and the kept SELECT policy shows
|
||||
// the result.
|
||||
const cancel = await client.query(
|
||||
`UPDATE public.supplier_payment_batches
|
||||
SET status = 'cancelled', cancelled_at = now(), cancelled_by = $2
|
||||
WHERE id = $1 AND status = 'created'`,
|
||||
[batchId, memberId],
|
||||
)
|
||||
const visible = await client.query<{ status: string }>(
|
||||
`SELECT status FROM public.supplier_payment_batches WHERE id = $1`,
|
||||
[batchId],
|
||||
)
|
||||
return { direct, result, items, cancelled: cancel.rowCount, visible: visible.rows }
|
||||
})
|
||||
|
||||
expect(outcome.direct?.code).toBe('42501')
|
||||
expect(outcome.direct?.message).toMatch(/row-level security/)
|
||||
expect(outcome.result.ok).toBe(true)
|
||||
if (!outcome.result.ok) throw new Error('unreachable')
|
||||
expect(outcome.result.batch.id).toBe(batchId)
|
||||
expect(outcome.result.batch.user_id).toBe(memberId)
|
||||
expect(outcome.items).toBe(1)
|
||||
expect(outcome.cancelled).toBe(1)
|
||||
expect(outcome.visible).toEqual([{ status: 'cancelled' }])
|
||||
})
|
||||
})
|
||||
|
||||
Reference in New Issue
Block a user