A refusal aimed at a field the form does not have shows nothing at all #76

New Issue

2026-09-21T07:18:23Z

cgalo5758 commented

2026-09-21 07:18:23 +00:00

What happens

A database constraint's refusal is mapped to the form field it belongs to, and the renderer writes the message under that field's control. When the form that was submitted has no such field, the message goes to a slot the page does not render: the operator gets their page back, refused, with no visible line anywhere saying why. The Extend grant form met this, because two grant constraints are mapped to a reason field that the Extend form does not carry. The submission that triggered it no longer happens, but the mapping is per constraint and shared by every form, so the next form that lacks a mapped field repeats it.

What should happen

Every refusal leaves one visible line. When the field a refusal names is not one of the submitted form's declared fields, the message falls back to the form's own error slot.

Where

internal/server/operator_enrollment.go, the refusal renderers and the helper that copies constraint errors onto a form; the forms library's error scoping.

Why it matters

A silent refusal is the worst answer a form can give. The values come back unchanged, nothing is marked, and the reasonable next act is to press the button again, which refuses again.

Done when a refusal naming an absent field renders in the form-level slot, and a test submits such a refusal and asserts the visible line.

Migrated from status/issues.md at b7a0e15

## What happens A database constraint's refusal is mapped to the form field it belongs to, and the renderer writes the message under that field's control. When the form that was submitted has no such field, the message goes to a slot the page does not render: the operator gets their page back, refused, with no visible line anywhere saying why. The Extend grant form met this, because two grant constraints are mapped to a reason field that the Extend form does not carry. The submission that triggered it no longer happens, but the mapping is per constraint and shared by every form, so the next form that lacks a mapped field repeats it. ## What should happen Every refusal leaves one visible line. When the field a refusal names is not one of the submitted form's declared fields, the message falls back to the form's own error slot. ## Where [`internal/server/operator_enrollment.go`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/internal/server/operator_enrollment.go), the refusal renderers and the helper that copies constraint errors onto a form; the forms library's error scoping. ## Why it matters A silent refusal is the worst answer a form can give. The values come back unchanged, nothing is marked, and the reasonable next act is to press the button again, which refuses again. Done when a refusal naming an absent field renders in the form-level slot, and a test submits such a refusal and asserts the visible line. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

bug

area/entitlements area/operator-ui labels 2026-09-21 07:18:23 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#76