Backend + frontend: edit/delete field definitions #36

New Issue

2026-06-04T12:36:46Z

logaritmisk commented

2026-06-04 12:36:46 +00:00

Context

The Fields Management milestone shipped create + list only for field definitions (POST/GET /api/admin/field-definitions). There is no way to edit a definition's labels/group/required flag, or to delete one. The db layer has only create_field_definition, field_definition_by_key, list_field_definitions — no update/delete functions.

Ask

db layer: add update_field_definition and delete_field_definition to crates/db/src/fields.rs.
api: PATCH /api/admin/field-definitions/{key} (edit labels / group / required — and decide whether data_type/key/binding are immutable; they likely should be, since changing a field's type invalidates existing object data) and DELETE /api/admin/field-definitions/{key}, both EditCatalogue.
frontend: extend the /fields screen — make list rows selectable/editable (likely a real detail/edit pane on the right instead of the always-create form, or an edit dialog), and a delete affordance.

The hard part — referential integrity (same class as #30)

A field definition is the schema that catalogue objects' flexible fields are validated and rendered against. Deleting or retyping a definition that objects already use is dangerous:

Delete: decide the policy — block with 409 + the list/count of objects using the field, or allow and define what happens to the stored values (orphaned JSON keys, or a cascading scrub). A "is this field referenced by any object?" check is needed (objects store flexible values keyed by field key).
required toggled on: existing objects may now violate the requirement — decide whether to block, or allow with a warning.
Type/key change: almost certainly disallow post-creation (immutable), since stored values can't be safely reinterpreted.

Acceptance

Update + delete endpoints with the referenced-entity policy defined and enforced (not a 500).
Immutable fields (key, data_type, binding) documented and rejected if changed.
Frontend edit/delete UI on /fields.
Writes audited (see #21, which already flags admin reference-data writes as unaudited).
OpenAPI regenerated.

## Context The Fields Management milestone shipped **create + list only** for field definitions (`POST`/`GET /api/admin/field-definitions`). There is no way to edit a definition's labels/group/required flag, or to delete one. The db layer has only `create_field_definition`, `field_definition_by_key`, `list_field_definitions` — no update/delete functions. ## Ask 1. **db layer:** add `update_field_definition` and `delete_field_definition` to `crates/db/src/fields.rs`. 2. **api:** `PATCH /api/admin/field-definitions/{key}` (edit labels / group / required — and decide whether `data_type`/`key`/binding are immutable; they likely should be, since changing a field's type invalidates existing object data) and `DELETE /api/admin/field-definitions/{key}`, both `EditCatalogue`. 3. **frontend:** extend the `/fields` screen — make list rows selectable/editable (likely a real detail/edit pane on the right instead of the always-create form, or an edit dialog), and a delete affordance. ## The hard part — referential integrity (same class as #30) A field definition is the **schema** that catalogue objects' flexible `fields` are validated and rendered against. Deleting or retyping a definition that objects already use is dangerous: - **Delete:** decide the policy — block with `409` + the list/count of objects using the field, or allow and define what happens to the stored values (orphaned JSON keys, or a cascading scrub). A "is this field referenced by any object?" check is needed (objects store flexible values keyed by field `key`). - **`required` toggled on:** existing objects may now violate the requirement — decide whether to block, or allow with a warning. - **Type/key change:** almost certainly disallow post-creation (immutable), since stored values can't be safely reinterpreted. ## Acceptance - Update + delete endpoints with the referenced-entity policy defined and enforced (not a 500). - Immutable fields (`key`, `data_type`, binding) documented and rejected if changed. - Frontend edit/delete UI on `/fields`. - Writes audited (see #21, which already flags admin reference-data writes as unaudited). - OpenAPI regenerated.