Files
accounted/lib/bookkeeping/__tests__/journal-entry-notes-immutability.pg.test.ts
T
Jakob Wennberg b5c3c3ec04 fix(reconciliation): surface bank tx + match to existing verifikat, delete UX, DPA links (#623)
* fix(reconciliation): surface bank transactions via robust cash_account_id scoping

The per-account reconciliation scoping silently returned zero transactions for
companies whose rows were NULL or mis-assigned mid-backfill (e.g. Arcim: 138
transactions, 101 unbooked, yet Bankavstämning showed "0 kr" while the 1930 GL
movement and a large difference still displayed). Two causes, both fixed:

- scopeTransactionsToAccount used a fragile nested or(...,and(is.null,...))
  PostgREST filter. Replace it with a flat, reliable
  `currency = X AND (cash_account_id = id OR cash_account_id IS NULL)` and share
  the one implementation with /api/transactions so the status card and the lists
  can never drift.
- The original best-effort backfill only touched NULL rows and an earlier
  revision mis-assigned cash_account_id (the since-fixed min(uuid) bug), which
  migrations cannot self-correct. Add an idempotent repair migration that
  re-seeds the default 1930 account and re-derives cash_account_id (correcting
  non-NULL mis-assignments) for booked rows and single-account companies.

Also localise manualLink's user-facing errors to Swedish. Adds unit coverage for
the new filter shape and pg-real coverage for the repair (incl. the Arcim
single-account reproduction).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(transactions): match a bank transaction to an existing verifikat

Adds a "Matcha mot befintlig verifikation" action to the Transactions inbox so a
bank line that is already booked elsewhere (a salary run, a Fortnox/manual
voucher, an invoice paid from the invoice page) can be linked to that existing
verifikat with no new bokföring — the capability previously lived only in
Reports → Bankavstämning.

- Extract the searchable MatchVerifikationPicker into a shared client component.
- New MatchVoucherDialog: resolves the tx's cash account, fetches candidates
  ranked server-side by reconciliation confidence, links via
  /api/reconciliation/bank/link (so the link is undoable in Bankavstämning).
- unmatched-entries route gains an optional transaction_id that ranks candidates
  (ranking stays server-side; the recon lib is not client-safe).
- Inbox row's overflow (⋯) menu gains the new action.

Also fixes the Bankavstämning view: editing the date no longer auto-reloads
(applies on Filtrera / account change only) and Datum till defaults to today.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(transactions): actionable Swedish errors when a bank tx cannot be deleted

The delete route returned a hardcoded English 409 that getErrorMessage mapped to
the misleading generic "En konflikt uppstod. Ladda om sidan...". Return
structured bilingual envelopes instead:

- TRANSACTION_DELETE_BOOKED (409) for a booked/linked row — steers the user to
  unlink in Bankavstämning or storna the voucher.
- TRANSACTION_DELETE_HAS_AUDIT_TRAIL (409) for the real, common case where an
  unbooked row carries payment_match_log rows: the cascade hits the
  audit-immutability trigger (P0001), previously surfaced as a bare 500. Steers
  the user to match-to-voucher or ignore instead.

Updates the DELETE test suite and adds the P0001 case.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(settings): surface DPA and privacy policy links

The /dpa page (personuppgiftsbiträdesavtal, GDPR Art. 28) was complete but
linked from nowhere. Add a "Sekretess och avtal" card on Inställningar → Konto
linking to /privacy and /dpa, and a reciprocal link to the DPA from the privacy
policy's sub-processor section. (The DPA already links back to /privacy.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(review): address PR #623 feedback

- unmatched-entries: when transaction_id is supplied but resolves to no row in
  the caller's company, return an empty candidate list instead of silently
  falling back to the full unranked list (Compliance Swarm V8.2.1, high).
- MatchVoucherDialog: preserve a manually-picked voucher when the candidate
  list reloads (e.g. "Visa alla datum") instead of discarding it (Greptile P2).
- DELETE /api/transactions/[id]: return the 404 as the structured
  { error: { code, message, message_en } } envelope like the handler's other
  errors, for a uniform contract (Greptile P2). Test updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(bookkeeping): allow editing notes on a committed journal entry

Saving a note on a posted verifikation failed with "Committed entries are
immutable": enforce_journal_entry_immutability() had no posted→posted path, so a
notes-only UPDATE fell through to the final RAISE. `notes` is internal annotation
metadata (not verifikation content under BFL 5 kap. / BFNAR 2013:2), so add a
narrow carve-out that permits a notes-only change on a committed entry — verified
with a whole-row to_jsonb() diff so any other field change still raises, and only
when status is unchanged. Period-lock enforcement is unaffected.

CREATE OR REPLACE in a new migration (same pattern as
20260428160000_fix_journal_entry_immutability_delete_bypass); the migration-017
protections are extended, never weakened. Covered by a pg-real test asserting a
notes edit succeeds while amount/description/account edits still fail.

(Already applied to production; committing the file + test for repo consistency.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(sandbox): make pre-staged pending operations executor-complete

The seeded pending_operations existed only as display previews — approving them
failed because commit executors in lib/pending-operations/commit.ts validate
required fields on "Godkänn". Seed a backing invoice_inbox_items row and fill the
supplier-invoice and categorize params with every field the executors require
(inbox_item_id, full items array; real uncategorized transaction_id + category),
so the sandbox approval queue is actually approvable end to end.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-01 21:08:06 +02:00

140 lines
5.5 KiB
TypeScript

import { randomUUID } from 'node:crypto'
import { describe, expect, it } from 'vitest'
import { getPool } from '@/tests/pg/setup'
import { insertBalancedLines, seedCompany } from '@/tests/pg/fixtures'
// Post a journal entry with balanced lines, going through draft so the
// line-immutability + balance triggers are satisfied. Returns the entry id.
async function insertPostedEntry(params: {
userId: string
companyId: string
fiscalPeriodId: string
voucherNumber: number
notes?: string | null
}): Promise<string> {
const id = randomUUID()
await getPool().query(
`INSERT INTO public.journal_entries
(id, user_id, company_id, fiscal_period_id, voucher_number, voucher_series,
entry_date, description, source_type, status, notes)
VALUES ($1, $2, $3, $4, $5, 'A', '2026-06-01', 'Test entry', 'manual', 'draft', $6)`,
[id, params.userId, params.companyId, params.fiscalPeriodId, params.voucherNumber, params.notes ?? null],
)
await insertBalancedLines(id)
await getPool().query(
`UPDATE public.journal_entries SET status = 'posted' WHERE id = $1`,
[id],
)
return id
}
describe('enforce_journal_entry_immutability.pg — notes-only edits', () => {
it('allows setting notes on a posted entry (the reported bug)', async () => {
const { userId, companyId, fiscalPeriodId } = await seedCompany()
const entryId = await insertPostedEntry({ userId, companyId, fiscalPeriodId, voucherNumber: 1 })
await getPool().query(
`UPDATE public.journal_entries SET notes = $1 WHERE id = $2`,
['Underlag saknas, frågar kunden', entryId],
)
const after = await getPool().query<{ notes: string | null; status: string }>(
`SELECT notes, status FROM public.journal_entries WHERE id = $1`,
[entryId],
)
expect(after.rows[0]!.notes).toBe('Underlag saknas, frågar kunden')
expect(after.rows[0]!.status).toBe('posted')
})
it('allows clearing notes (set to NULL) on a posted entry', async () => {
const { userId, companyId, fiscalPeriodId } = await seedCompany()
const entryId = await insertPostedEntry({
userId, companyId, fiscalPeriodId, voucherNumber: 1, notes: 'existing note',
})
await getPool().query(
`UPDATE public.journal_entries SET notes = NULL WHERE id = $1`,
[entryId],
)
const after = await getPool().query<{ notes: string | null }>(
`SELECT notes FROM public.journal_entries WHERE id = $1`,
[entryId],
)
expect(after.rows[0]!.notes).toBeNull()
})
it('allows notes edits on a reversed entry', async () => {
const { userId, companyId, fiscalPeriodId } = await seedCompany()
const entryId = await insertPostedEntry({ userId, companyId, fiscalPeriodId, voucherNumber: 1 })
await getPool().query(
`UPDATE public.journal_entries SET status = 'reversed' WHERE id = $1`,
[entryId],
)
await getPool().query(
`UPDATE public.journal_entries SET notes = 'Makulerad pga dubbelbokning' WHERE id = $1`,
[entryId],
)
const after = await getPool().query<{ notes: string | null; status: string }>(
`SELECT notes, status FROM public.journal_entries WHERE id = $1`,
[entryId],
)
expect(after.rows[0]!.notes).toBe('Makulerad pga dubbelbokning')
expect(after.rows[0]!.status).toBe('reversed')
})
it('still blocks editing a bookkeeping field on a posted entry', async () => {
const { userId, companyId, fiscalPeriodId } = await seedCompany()
const entryId = await insertPostedEntry({ userId, companyId, fiscalPeriodId, voucherNumber: 1 })
await expect(
getPool().query(
`UPDATE public.journal_entries SET description = 'tampered' WHERE id = $1`,
[entryId],
),
).rejects.toThrow(/Cannot modify a posted journal entry/i)
})
// Defense in depth: a real bookkeeping change must not slip through just
// because `notes` also changed in the same UPDATE. The to_jsonb diff sees
// the entry_date change and the whole statement is rejected.
it('blocks a notes edit bundled with a bookkeeping field change', async () => {
const { userId, companyId, fiscalPeriodId } = await seedCompany()
const entryId = await insertPostedEntry({ userId, companyId, fiscalPeriodId, voucherNumber: 1 })
await expect(
getPool().query(
`UPDATE public.journal_entries
SET notes = 'looks innocent', entry_date = '2026-07-01'
WHERE id = $1`,
[entryId],
),
).rejects.toThrow(/Cannot modify a posted journal entry/i)
const after = await getPool().query<{ notes: string | null; entry_date: string }>(
`SELECT notes, entry_date::text FROM public.journal_entries WHERE id = $1`,
[entryId],
)
expect(after.rows[0]!.notes).toBeNull()
expect(after.rows[0]!.entry_date).toBe('2026-06-01')
})
// Scope guard: notes carve-out does NOT override the period lock. Editing
// notes on a committed entry in a locked period is still rejected by
// enforce_period_lock (which fires after this trigger).
it('still blocks notes edits when the fiscal period is locked', async () => {
const { userId, companyId, fiscalPeriodId } = await seedCompany()
const entryId = await insertPostedEntry({ userId, companyId, fiscalPeriodId, voucherNumber: 1 })
await getPool().query(
`UPDATE public.fiscal_periods SET locked_at = now() WHERE id = $1`,
[fiscalPeriodId],
)
await expect(
getPool().query(
`UPDATE public.journal_entries SET notes = 'too late' WHERE id = $1`,
[entryId],
),
).rejects.toThrow(/locked\/closed fiscal period/i)
})
})