feat: replace dropdowns with individual fields for body dimensions

2026-05-28 13:59:30 +02:00
parent fa7e5c2091
commit bdf8cffd04
8 changed files with 366 additions and 148 deletions
@@ -0,0 +1,120 @@
+# Body Dimensions Transition Plan (Stakeholder Draft)
+
+## Goal
+
+Prevent edit-form failures for existing bookings while we transition from legacy body-dimension values to a better long-term field model.
+
+This plan introduces a temporary compatibility phase and keeps sunsetting manual and straightforward.
+
+## Current Problem
+
+- Existing bookings may contain legacy values such as `-148`, `149-157`, or `195+`.
+- Integer-only form fields can fail when these legacy strings are loaded.
+- Result: participant edit forms can crash before submit.
+
+## Proposed Transition Strategy
+
+Use **text input fields** for body dimensions during transition, with explicit server-side format validation.
+
+### Key Decisions
+
+- No gating by booking create date.
+- One unified behavior for all bookings.
+- Accept both legacy and numeric formats during transition.
+- Keep manual sunsetting later (no automated migration switch).
+
+## Functional Scope
+
+Affected fields:
+
+- `height`
+- `weight`
+- `shoeSize`
+
+Affected components:
+
+- `src/Form/BodyDimensionsType.php`
+- `src/Validator/Constraints/ParticipantValidator.php`
+- `src/Form/BookingParticipantType.php` (option passthrough already in place)
+- `config/services.yaml` (ranges remain as validation/config source)
+
+## Validation Rules During Transition
+
+### Accepted formats
+
+- Numeric value: `^\d+$` (e.g. `176`)
+- Legacy lower/open/range tokens:
+  - `^-\d+$` (e.g. `-148`)
+  - `^\d+\+$` (e.g. `195+`)
+  - `^\d+\s*-\s*\d+$` (e.g. `149-157`)
+
+### Requiredness
+
+- Keep existing rule: body dimensions required when rentals are selected.
+
+### Range checks
+
+- Keep current numeric range checks based on `body_dimension_ranges`.
+- Apply range checks only to plain numeric values in transition phase.
+
+## UX/Behavior Expectations
+
+- Existing legacy values render without form initialization errors.
+- New numeric entries are accepted and validated.
+- Invalid free text (e.g. `abc`, `17x`) shows clear validation errors.
+- HTMX refresh behavior remains unchanged.
+
+## Implementation Steps
+
+1. **Form type change**
+   - In `BodyDimensionsType`, replace integer fields with text fields for all three body dimensions.
+   - Keep labels/help text; keep placeholders based on configured ranges.
+
+2. **Validator extension**
+   - Add format validation for all three fields in `ParticipantValidator`.
+   - Keep existing required-when-rentals logic.
+   - Keep existing range validation for numeric values.
+
+3. **Message tuning**
+   - Add one clear message for invalid format.
+   - Retain existing range message for numeric out-of-range values.
+
+4. **Testing and QA**
+   - Validate old bookings with legacy values open/edit successfully.
+   - Validate numeric path (valid and invalid range).
+   - Validate invalid format handling.
+   - Validate rental-required behavior.
+
+## Acceptance Criteria
+
+- No 500 error when editing participants with legacy body-dimension values.
+- Legacy values can be loaded and submitted in transition phase.
+- Numeric values are accepted and range-validated.
+- Invalid text is rejected with a user-facing validation message.
+- Existing participant edit/refresh flows continue to work.
+
+## Risks and Mitigations
+
+- **Risk:** Free-text field semantics are less strict than integer fields.
+  - **Mitigation:** strict server-side regex + range checks.
+
+- **Risk:** Inconsistent data representations during transition.
+  - **Mitigation:** explicit acceptance policy and manual sunset plan.
+
+## Effort Estimate
+
+- Implementation: 0.5 day
+- Validation/message tuning: 0.25 day
+- QA/manual testing: 0.5 day
+- **Total:** ~1 to 1.5 days
+
+## Manual Sunset Plan (Later)
+
+When stakeholders approve end of transition:
+
+1. Replace text fields with final semantic field type(s).
+2. Remove legacy format acceptance from validator.
+3. Keep only final numeric/range validation behavior.
+4. Remove transition-specific tests and copy.
+
+Expected cleanup effort: ~0.25 to 0.5 day.