53ab6b92b53a7062e680a1b228cb6f0f7c76d7c5
The database already permitted all three (forms admin manage is FOR ALL); this was purely a missing UI. Create and edit now share one editor, since the only differences are the initial values and insert vs update. Three hazards in the existing data model shaped this rather than just adding buttons: - form_responses.form_id is ON DELETE CASCADE, so deleting a form permanently destroys its submissions. The confirmation names the response count and points to deactivating instead. Verified: deleting a form with two responses leaves zero. - The list filtered active = true for everyone, so deactivating a form hid it from the only people who could reactivate it. Admins now see inactive forms with a badge; families still see only active ones. - Responses key their answers by field *label* in data_json, so renaming a field strands existing answers under the old key. The editor warns when the form already has responses. Deliberately not migrating old answers — guessing which old label maps to which new one would risk silently rewriting submitted data. Also strips fields with blank labels on save, shows a response count per form, and gives the response list an empty state. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
1 MiB
Languages
JavaScript
42.2%
Dockerfile
30.4%
TypeScript
27.4%