Files
accounted/lib/pending-operations/schemas/__tests__/customer.test.ts
T
MattssonandClaude Fable 5 77cacdcf34 feat(mcp): personal_number on gnubok_update_customer (#1876) (#1890)
gnubok_create_customer takes a personnummer (encrypted before approval)
but gnubok_update_customer did not, so an existing customer whose
personnummer sat in the org-number field could not be corrected via MCP.
The REST PATCH already supports it; this closes the MCP/pending-operations
gap across its three layers:

- tool inputSchema: personal_number (string or null) on the strict
  whitelist. The tool validates the plaintext before any DB read and
  mirrors the REST PATCH semantics: masked echo (********-1234 or
  ********-????) = leave unchanged, explicit null = clear, absent =
  untouched. Setting is refused unless the row ends up as an individual
  (GDPR art. 5.1 c), including via a simultaneous type change.
- CustomerChangesSchema: personal_number_encrypted (nullable, ciphertext
  shape per customers_personal_number_check 20260726110000). The
  plaintext key stays forbidden by .strict() and staging-pii-guard.
- update executor: maps the staged ciphertext onto customers
  .personal_number (set/clear/leave), re-checks the individual-only rule
  against a tampered row, and returns only personal_number_masked.

PII handling: the personnummer is encrypted at staging time
(AES-256-GCM, same path as create); pending_operations params carry only
the ciphertext and the approval preview only the masked form. Idempotency
hashing switches to the masked preview for personnummer-bearing updates
(random-IV ciphertext would break retries); other updates keep their
previous hash identity.

catalogVisibility stays 'search': tools/list is at its 59.95K token
ceiling with zero headroom (see DECISIONS.md).

Fixes #1876

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 14:35:02 +02:00

53 lines
1.8 KiB
TypeScript

import { describe, it, expect } from 'vitest'
import { encryptPersonnummer } from '@/lib/salary/personnummer'
import { UpdateCustomerParamsSchema } from '../customer'
const CUSTOMER_ID = '11111111-1111-4111-8111-111111111111'
const wrap = (changes: Record<string, unknown>) => ({
customer_id: CUSTOMER_ID,
changes,
})
// Synthetic personnummer, never a real one.
const PERSONAL_NUMBER = '19900101-1234'
describe('UpdateCustomerParamsSchema: personal_number_encrypted (#1876)', () => {
it('accepts AES-256-GCM ciphertext', () => {
const encrypted = encryptPersonnummer(PERSONAL_NUMBER)
const parsed = UpdateCustomerParamsSchema.parse(
wrap({ personal_number_encrypted: encrypted }),
)
expect(parsed.changes.personal_number_encrypted).toBe(encrypted)
})
it('accepts explicit null (clears the stored value at commit)', () => {
const parsed = UpdateCustomerParamsSchema.parse(
wrap({ personal_number_encrypted: null }),
)
expect(parsed.changes.personal_number_encrypted).toBeNull()
})
it('rejects a plaintext personnummer under personal_number_encrypted', () => {
expect(() =>
UpdateCustomerParamsSchema.parse(wrap({ personal_number_encrypted: PERSONAL_NUMBER })),
).toThrow(/encrypted personal number/i)
})
it('rejects the plaintext personal_number key (strict schema)', () => {
expect(() =>
UpdateCustomerParamsSchema.parse(wrap({ personal_number: PERSONAL_NUMBER })),
).toThrow(/unrecognized key/i)
})
it('still rejects unknown fields', () => {
expect(() =>
UpdateCustomerParamsSchema.parse(wrap({ company_id: 'other-company' })),
).toThrow(/unrecognized key/i)
})
it('still requires at least one changed field', () => {
expect(() => UpdateCustomerParamsSchema.parse(wrap({}))).toThrow(/at least one/i)
})
})