Test gaps: field-definition 403 (backend) + authority-kind reveal (frontend) #37

New Issue

2026-06-04T12:36:53Z

logaritmisk commented

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

Minor test-coverage gaps noted in the Fields Management final review (non-blocking):

Backend 403 path. crates/api/tests/admin_fields.rs covers 401 (unauthenticated) but not authenticated-with-insufficient-capability → 403. The Authorized<EditCatalogue> extractor is exercised by other test files, so risk is low, but a dedicated case (e.g. a viewer/read-only role POSTing → 403) would close the gap. (Confirm a non-EditCatalogue role exists to seed.)
Frontend authority-kind reveal. web/src/fields/fields.test.tsx covers the Term branch (selecting type=term reveals the vocabulary picker and blocks submit until one is chosen) but not the Authority branch (field-form.tsx dataType === "authority" → the kind <select> with Any/Person/Organisation/Place). A test that selects type=authority, picks a kind, and asserts the posted authority_kind would cover it. (The backend create_authority_field test already covers the API side.)

Both are low-priority polish — the happy paths and the more complex Term branch are covered.

Minor test-coverage gaps noted in the Fields Management final review (non-blocking): 1. **Backend 403 path.** `crates/api/tests/admin_fields.rs` covers `401` (unauthenticated) but not authenticated-with-insufficient-capability → `403`. The `Authorized<EditCatalogue>` extractor is exercised by other test files, so risk is low, but a dedicated case (e.g. a viewer/read-only role POSTing → 403) would close the gap. (Confirm a non-`EditCatalogue` role exists to seed.) 2. **Frontend authority-kind reveal.** `web/src/fields/fields.test.tsx` covers the **Term** branch (selecting type=term reveals the vocabulary picker and blocks submit until one is chosen) but not the **Authority** branch (`field-form.tsx` `dataType === "authority"` → the kind `<select>` with Any/Person/Organisation/Place). A test that selects type=authority, picks a kind, and asserts the posted `authority_kind` would cover it. (The backend `create_authority_field` test already covers the API side.) Both are low-priority polish — the happy paths and the more complex Term branch are covered.

logaritmisk commented

2026-06-04 15:40:36 +00:00

Resolved in 0d971cd:

Frontend authority-kind reveal test — added to web/src/fields/fields.test.tsx (selects the Authority type, picks a kind, asserts the posted authority_kind). Done.
Backend 403 test — not feasible today and intentionally skipped. Only two roles exist (Admin, Editor) and both grant EditCatalogue, so no authenticated user can receive a 403 on field-definition create — there is nothing to assert. When a read-only/viewer role is introduced, the 403 coverage should be added then (it'll come naturally with that role's tests).

Closing as done for the actionable scope; the 403 case will be picked up with a future viewer role.

Resolved in `0d971cd`: - **Frontend authority-kind reveal test** — added to `web/src/fields/fields.test.tsx` (selects the Authority type, picks a kind, asserts the posted `authority_kind`). Done. - **Backend 403 test** — **not feasible today and intentionally skipped.** Only two roles exist (`Admin`, `Editor`) and *both* grant `EditCatalogue`, so no authenticated user can receive a 403 on field-definition create — there is nothing to assert. When a read-only/viewer role is introduced, the 403 coverage should be added then (it'll come naturally with that role's tests). Closing as done for the actionable scope; the 403 case will be picked up with a future viewer role.

logaritmisk closed this issue

2026-06-04 15:40:36 +00:00

logaritmisk referenced this issue from a commit

2026-06-04 17:41:31 +00:00

fix(web): search 503 vs error (#34); terms/authorities list error states (#31); authority-tab a11y + dead keys (#32); authority-kind test (#37)

logaritmisk referenced this issue from a commit

2026-06-04 17:41:31 +00:00

merge: tier 2 papercuts (#22 #18 #9 #4 #34 #31 #32 #37)

Sign in to join this conversation.