logaritmisk/biggus-dickus
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases Wiki Activity

Backend: edit/delete endpoints for vocabularies, terms, and authorities #30

New Issue
Closed
opened 2026-06-04 07:43:21 +00:00 by logaritmisk · 1 comment
logaritmisk commented 2026-06-04 07:43:21 +00:00
Owner
Copy Link
Copy Source

Context

The admin reference-data surface currently exposes create + list only:

  • GET/POST /api/admin/vocabularies
  • GET/POST /api/admin/vocabularies/{id}/terms
  • GET/POST /api/admin/authorities?kind=

Frontend Milestone 4 (vocabulary & authority management) was therefore deliberately scoped to create + list — there is no UI to rename a vocabulary, correct a term's labels/URI, fix a misspelled authority, or remove an erroneous entry. In a cataloguing system this is a real operational gap: reference data accrues mistakes that currently can only be fixed by direct DB edits.

Ask

Add update/delete endpoints (and the corresponding db/api layer functions), e.g.:

  • PATCH /api/admin/vocabularies/{id} (rename key) — or decide keys are immutable and document why
  • PATCH /api/admin/vocabularies/{id}/terms/{term_id} (edit labels / external_uri)
  • DELETE /api/admin/vocabularies/{id}/terms/{term_id}
  • PATCH /api/admin/authorities/{id} (edit labels / external_uri)
  • DELETE /api/admin/authorities/{id}
  • Vocabulary delete is the thorny one — decide cascade vs. block-when-referenced.

Considerations

  • Referential integrity: terms/authorities are referenced by catalogue object fields. Deleting one that's in use must either be blocked (409 with referencing-object info) or handled explicitly — decide the policy. This likely needs a "is this referenced?" check.
  • Audit: these admin writes should be audited (see #21, which already flags create as unaudited — extend it to edit/delete).
  • Once shipped: unblocks a follow-on frontend milestone to add edit/delete UI to the vocab + authorities screens (the screens are built to extend cleanly — list items would gain edit/delete affordances).

Acceptance

  • Update + delete endpoints for term and authority at minimum; vocabulary delete policy decided and implemented.
  • Referenced-entity deletion policy defined and enforced (not a 500).
  • Writes audited.
  • OpenAPI schema regenerated so the typed web client picks them up.
## Context The admin reference-data surface currently exposes **create + list only**: - `GET/POST /api/admin/vocabularies` - `GET/POST /api/admin/vocabularies/{id}/terms` - `GET/POST /api/admin/authorities?kind=` Frontend Milestone 4 (vocabulary & authority management) was therefore deliberately scoped to **create + list** — there is no UI to rename a vocabulary, correct a term's labels/URI, fix a misspelled authority, or remove an erroneous entry. In a cataloguing system this is a real operational gap: reference data accrues mistakes that currently can only be fixed by direct DB edits. ## Ask Add update/delete endpoints (and the corresponding `db`/`api` layer functions), e.g.: - `PATCH /api/admin/vocabularies/{id}` (rename `key`) — or decide keys are immutable and document why - `PATCH /api/admin/vocabularies/{id}/terms/{term_id}` (edit labels / `external_uri`) - `DELETE /api/admin/vocabularies/{id}/terms/{term_id}` - `PATCH /api/admin/authorities/{id}` (edit labels / `external_uri`) - `DELETE /api/admin/authorities/{id}` - Vocabulary delete is the thorny one — decide cascade vs. block-when-referenced. ## Considerations - **Referential integrity:** terms/authorities are referenced by catalogue object fields. Deleting one that's in use must either be blocked (409 with referencing-object info) or handled explicitly — decide the policy. This likely needs a "is this referenced?" check. - **Audit:** these admin writes should be audited (see #21, which already flags create as unaudited — extend it to edit/delete). - **Once shipped:** unblocks a follow-on frontend milestone to add edit/delete UI to the vocab + authorities screens (the screens are built to extend cleanly — list items would gain edit/delete affordances). ## Acceptance - Update + delete endpoints for term and authority at minimum; vocabulary delete policy decided and implemented. - Referenced-entity deletion policy defined and enforced (not a 500). - Writes audited. - OpenAPI schema regenerated so the typed web client picks them up.
logaritmisk commented 2026-06-05 20:30:31 +00:00
Author
Owner
Copy Link
Copy Source

Done in 873efe1 (merged to main). Added audited PATCH/DELETE for terms, vocabularies (rename), and authorities. Referenced-entity deletes are blocked with 409 + count (JSONB scan of object.fields); vocabulary delete is blocked when it has terms or is bound by a field definition. Frontend: in-place edit + AlertDialog delete on the vocabularies and authorities screens, surfacing the "used by N" message. Field definitions are covered by #36 (same milestone).

Done in `873efe1` (merged to `main`). Added audited `PATCH`/`DELETE` for terms, vocabularies (rename), and authorities. Referenced-entity deletes are blocked with **409 + count** (JSONB scan of `object.fields`); vocabulary delete is blocked when it has terms or is bound by a field definition. Frontend: in-place edit + `AlertDialog` delete on the vocabularies and authorities screens, surfacing the "used by N" message. Field definitions are covered by #36 (same milestone).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
logaritmisk
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#30
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?