MattssonandClaude Fable 5
77cacdcf34
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
2.0 KiB
TypeScript
53 lines
2.0 KiB
TypeScript
import { z } from 'zod'
|
|
import { UpdateCustomerSchema } from '@/lib/api/schemas'
|
|
|
|
const CustomerChangesSchema = z
|
|
.object({
|
|
name: UpdateCustomerSchema.shape.name,
|
|
customer_type: UpdateCustomerSchema.shape.customer_type,
|
|
customer_number: UpdateCustomerSchema.shape.customer_number,
|
|
email: UpdateCustomerSchema.shape.email,
|
|
phone: UpdateCustomerSchema.shape.phone,
|
|
address_line1: UpdateCustomerSchema.shape.address_line1,
|
|
address_line2: UpdateCustomerSchema.shape.address_line2,
|
|
postal_code: UpdateCustomerSchema.shape.postal_code,
|
|
city: UpdateCustomerSchema.shape.city,
|
|
country: UpdateCustomerSchema.shape.country,
|
|
org_number: UpdateCustomerSchema.shape.org_number,
|
|
vat_number: UpdateCustomerSchema.shape.vat_number,
|
|
language: UpdateCustomerSchema.shape.language,
|
|
default_payment_terms: UpdateCustomerSchema.shape.default_payment_terms,
|
|
notes: UpdateCustomerSchema.shape.notes,
|
|
// The personnummer, already encrypted at staging time: the MCP tool
|
|
// validates the plaintext (REST semantics: a masked echo is dropped
|
|
// before it gets here) and stores only AES-256-GCM ciphertext, because
|
|
// staging-pii-guard.ts forbids the plaintext personal_number key in
|
|
// pending_operations payloads. Ciphertext shape mirrors
|
|
// customers_personal_number_check (20260726110000). At commit: string
|
|
// sets the stored value, explicit null clears it, absent leaves it
|
|
// untouched.
|
|
personal_number_encrypted: z
|
|
.string()
|
|
.regex(/^[0-9a-f]{76,255}$/, 'Invalid encrypted personal number')
|
|
.nullable()
|
|
.optional(),
|
|
})
|
|
.strict()
|
|
.superRefine((changes, ctx) => {
|
|
if (Object.keys(changes).length === 0) {
|
|
ctx.addIssue({
|
|
code: 'custom',
|
|
message: 'At least one customer field must be supplied',
|
|
})
|
|
}
|
|
})
|
|
|
|
export const UpdateCustomerParamsSchema = z
|
|
.object({
|
|
customer_id: z.string().uuid(),
|
|
changes: CustomerChangesSchema,
|
|
})
|
|
.strict()
|
|
|
|
export type UpdateCustomerParams = z.infer<typeof UpdateCustomerParamsSchema>
|