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>
53 lines
1.8 KiB
TypeScript
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)
|
|
})
|
|
})
|