* fix(payroll): enforce the jamkning both-dates invariant with a database trigger Root cause: PR #2240 made every application write path refuse a jamkning_percentage without both jamkning_valid_from and jamkning_valid_to (validateJamkning), but the rule lived only in application code. Two writes could still store the inert shape the engine never applies: (1) concurrent PATCHes, where both handlers validate a fetched snapshot and then issue an unconditional partial update, so a { jamkning_valid_to: null } that committed last left a percentage without an end date; (2) direct SQL and service-role writes, which bypass the validator entirely. Fix: migration 20260904120000 adds trg_enforce_employee_jamkning_dates, BEFORE INSERT OR UPDATE OF jamkning_percentage, jamkning_valid_from, jamkning_valid_to ON employees. It mirrors validateJamkning: a non-null percentage needs both dates, and valid_to may not precede valid_from. On INSERT it always checks; on UPDATE it checks only when one of the three columns actually changes (IS DISTINCT FROM on OLD vs NEW), so a legacy incomplete row stored before #2240 stays editable in unrelated ways, including by a route that writes the whole row back. The error is SQLSTATE 23514 with the stable prefix "JAMKNING_INCOMPLETE: " followed by the same Swedish sentence the validator produces. The function is SECURITY INVOKER with search_path pinned. No backfill: existing incomplete rows are listed by scripts/list-incomplete-jamkning.ts and decided per company. App side, jamkningIssueFromDbError in lib/salary/jamkning-rules.ts recognises the trigger rejection, and the three update paths (dashboard PATCH, v1 PATCH, MCP update_employee executor) answer it with the same 400 / VALIDATION_ERROR and sentence as the merged-state check, instead of a generic 500 / INTERNAL_ERROR. Tests: tests/pg/employees-jamkning-trigger.pg.test.ts (25 cases against real Postgres, including the interleaved two-transaction race), unit tests for the helper, and one race test per update path. Fixes #2256 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u * fix(payroll): enforce the jamkning both-dates invariant with a CHECK constraint Root cause: PR #2240 made every application write path refuse a jamkning_percentage without both jamkning_valid_from and jamkning_valid_to (validateJamkning), but the rule lived only in application code, across many writers. Two concurrent PATCHes that each validated a fetched snapshot and then wrote unconditionally could leave a percentage without an end date (the engine never applies such a beslut, so the payslip and AGI silently carry the table tax), and direct SQL or service-role writes never saw the validator at all. Fix, from first principles: the invariant is a row-level fact, so it is declared as a row-level CHECK constraint, employees_jamkning_dates_check (migration 20260904120000), added NOT VALID so the migration cannot fail on production because of rows stored incomplete before #2240. From now on every INSERT and every UPDATE of any row is checked. This replaces the trigger the issue proposed: no plpgsql function, no per-column change detection, no custom message convention, and the rule is visible in the schema. One behavioural difference from the proposal: a legacy incomplete row is refused on its next edit, related or not, until the beslut is completed (both dates) or cleared (percentage null). The application maps that rejection (SQLSTATE 23514 naming the constraint) to the validator's own Swedish sentence in the three update paths (dashboard PATCH, v1 PATCH, MCP update_employee executor), so the user is told exactly what to complete; a rejection the merged row cannot explain (a concurrent change) gets an umbrella sentence. No backfill: those rows are listed by scripts/list-incomplete-jamkning.ts and decided per company. Tests: tests/pg/employees-jamkning-check.pg.test.ts against real Postgres (constraint shape, INSERT and UPDATE rejections and acceptances, the interleaved two-transaction race, the legacy consequence), unit tests for the mapping, and race plus legacy tests per update path. The PostgREST error shape was verified against a real PostgREST: the constraint name is in `message`, `details` carries the failing row and is never forwarded. Fixes #2256 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>
175 lines
6.6 KiB
TypeScript
175 lines
6.6 KiB
TypeScript
import { describe, it, expect } from 'vitest'
|
|
import {
|
|
JAMKNING_CHECK_CONSTRAINT,
|
|
JAMKNING_END_REQUIRED,
|
|
JAMKNING_ORDER,
|
|
JAMKNING_ROW_INCOMPLETE,
|
|
JAMKNING_START_REQUIRED,
|
|
jamkningIssueFromDbError,
|
|
touchesJamkning,
|
|
validateJamkning,
|
|
} from '../jamkning-rules'
|
|
|
|
describe('validateJamkning', () => {
|
|
it('accepts a complete beslut', () => {
|
|
expect(
|
|
validateJamkning({
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-01-01',
|
|
jamkning_valid_to: '2026-12-31',
|
|
}),
|
|
).toEqual([])
|
|
})
|
|
|
|
it('accepts no beslut at all, with or without stray dates', () => {
|
|
expect(validateJamkning({})).toEqual([])
|
|
expect(
|
|
validateJamkning({ jamkning_percentage: null, jamkning_valid_from: null, jamkning_valid_to: null }),
|
|
).toEqual([])
|
|
expect(
|
|
validateJamkning({ jamkning_percentage: null, jamkning_valid_from: '2026-01-01', jamkning_valid_to: null }),
|
|
).toEqual([])
|
|
})
|
|
|
|
it('requires the start date when a percentage is set', () => {
|
|
const issues = validateJamkning({
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: null,
|
|
jamkning_valid_to: '2026-12-31',
|
|
})
|
|
expect(issues).toEqual([{ field: 'jamkning_valid_from', message: JAMKNING_START_REQUIRED }])
|
|
})
|
|
|
|
it('requires the end date when a percentage is set (#2058: the engine never applies a beslut without it)', () => {
|
|
const issues = validateJamkning({
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-01-01',
|
|
jamkning_valid_to: null,
|
|
})
|
|
expect(issues).toEqual([{ field: 'jamkning_valid_to', message: JAMKNING_END_REQUIRED }])
|
|
})
|
|
|
|
it('treats an undefined end date like a null one', () => {
|
|
const issues = validateJamkning({ jamkning_percentage: 15, jamkning_valid_from: '2026-01-01' })
|
|
expect(issues.map((i) => i.field)).toEqual(['jamkning_valid_to'])
|
|
})
|
|
|
|
it('treats 0 % as a beslut (Skatteverket can decide on zero withholding)', () => {
|
|
const issues = validateJamkning({ jamkning_percentage: 0, jamkning_valid_from: null, jamkning_valid_to: null })
|
|
expect(issues.map((i) => i.field)).toEqual(['jamkning_valid_from', 'jamkning_valid_to'])
|
|
})
|
|
|
|
it('reports both missing dates in field order', () => {
|
|
const issues = validateJamkning({ jamkning_percentage: 15 })
|
|
expect(issues).toEqual([
|
|
{ field: 'jamkning_valid_from', message: JAMKNING_START_REQUIRED },
|
|
{ field: 'jamkning_valid_to', message: JAMKNING_END_REQUIRED },
|
|
])
|
|
})
|
|
|
|
it('rejects an end date before the start date', () => {
|
|
const issues = validateJamkning({
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-06-01',
|
|
jamkning_valid_to: '2026-01-31',
|
|
})
|
|
expect(issues).toEqual([{ field: 'jamkning_valid_to', message: JAMKNING_ORDER }])
|
|
})
|
|
|
|
it('checks date ordering even without a percentage (schema body-only use)', () => {
|
|
const issues = validateJamkning({
|
|
jamkning_percentage: null,
|
|
jamkning_valid_from: '2026-06-01',
|
|
jamkning_valid_to: '2026-01-31',
|
|
})
|
|
expect(issues).toEqual([{ field: 'jamkning_valid_to', message: JAMKNING_ORDER }])
|
|
})
|
|
|
|
it('accepts a one-day window', () => {
|
|
expect(
|
|
validateJamkning({
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-03-01',
|
|
jamkning_valid_to: '2026-03-01',
|
|
}),
|
|
).toEqual([])
|
|
})
|
|
})
|
|
|
|
describe('touchesJamkning', () => {
|
|
it('is true for any jämkning key, including an explicit null', () => {
|
|
expect(touchesJamkning({ jamkning_percentage: 15 })).toBe(true)
|
|
expect(touchesJamkning({ jamkning_valid_from: null })).toBe(true)
|
|
expect(touchesJamkning({ jamkning_valid_to: '2026-12-31' })).toBe(true)
|
|
})
|
|
|
|
it('is false for an unrelated patch, so legacy rows stay editable', () => {
|
|
expect(touchesJamkning({ first_name: 'Ny', monthly_salary: 38000 })).toBe(false)
|
|
expect(touchesJamkning({})).toBe(false)
|
|
})
|
|
})
|
|
|
|
// The PostgREST error for a violated CHECK constraint, as observed against a
|
|
// real PostgREST (tests/tool-pg): the constraint name is in `message` only,
|
|
// and `details` carries the failing row, which no caller may echo.
|
|
const CHECK_ERROR = {
|
|
code: '23514',
|
|
details: 'Failing row contains (...).',
|
|
hint: null,
|
|
message: `new row for relation "employees" violates check constraint "${JAMKNING_CHECK_CONSTRAINT}"`,
|
|
}
|
|
|
|
describe('jamkningIssueFromDbError (#2256: the CHECK constraint backstop)', () => {
|
|
it('recovers the validator sentence from the merged row (a legacy incomplete row on its next edit)', () => {
|
|
expect(
|
|
jamkningIssueFromDbError(CHECK_ERROR, {
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-01-01',
|
|
jamkning_valid_to: null,
|
|
}),
|
|
).toEqual({ field: 'jamkning_valid_to', message: JAMKNING_END_REQUIRED })
|
|
expect(
|
|
jamkningIssueFromDbError(CHECK_ERROR, { jamkning_percentage: 15, jamkning_valid_from: null, jamkning_valid_to: null }),
|
|
).toEqual({ field: 'jamkning_valid_from', message: JAMKNING_START_REQUIRED })
|
|
expect(
|
|
jamkningIssueFromDbError(CHECK_ERROR, {
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-06-01',
|
|
jamkning_valid_to: '2026-01-31',
|
|
}),
|
|
).toEqual({ field: 'jamkning_valid_to', message: JAMKNING_ORDER })
|
|
})
|
|
|
|
it('falls back to the umbrella sentence when the merged row is valid (a concurrent change)', () => {
|
|
expect(
|
|
jamkningIssueFromDbError(CHECK_ERROR, {
|
|
jamkning_percentage: 15,
|
|
jamkning_valid_from: '2026-01-01',
|
|
jamkning_valid_to: '2026-12-31',
|
|
}),
|
|
).toEqual({ field: 'jamkning_valid_to', message: JAMKNING_ROW_INCOMPLETE })
|
|
expect(jamkningIssueFromDbError(CHECK_ERROR)).toEqual({ field: 'jamkning_valid_to', message: JAMKNING_ROW_INCOMPLETE })
|
|
})
|
|
|
|
it('accepts the node-postgres shape, which names the constraint in its own field', () => {
|
|
expect(
|
|
jamkningIssueFromDbError({ code: '23514', message: 'anything', constraint: JAMKNING_CHECK_CONSTRAINT }),
|
|
).toEqual({ field: 'jamkning_valid_to', message: JAMKNING_ROW_INCOMPLETE })
|
|
})
|
|
|
|
it('ignores every other error', () => {
|
|
expect(jamkningIssueFromDbError(null)).toBeNull()
|
|
expect(jamkningIssueFromDbError(CHECK_ERROR.message)).toBeNull()
|
|
// Another CHECK constraint on the same table.
|
|
expect(
|
|
jamkningIssueFromDbError({
|
|
code: '23514',
|
|
message: 'new row for relation "employees" violates check constraint "employees_tax_column_check"',
|
|
}),
|
|
).toBeNull()
|
|
// The constraint name under a different SQLSTATE is not the constraint.
|
|
expect(jamkningIssueFromDbError({ code: 'P0001', message: CHECK_ERROR.message })).toBeNull()
|
|
expect(jamkningIssueFromDbError({ code: '23514' })).toBeNull()
|
|
})
|
|
})
|