123 lines
4.1 KiB
Markdown
123 lines
4.1 KiB
Markdown
# Body Dimensions Transition Plan (Stakeholder Draft)
|
|
|
|
> **STATUS (verified 2026-07-15): NOT IMPLEMENTED.** `src/Form/BodyDimensionsType.php` still declares `height`, `shoeSize`, and `weight` as `IntegerType` fields, and `src/Validator/Constraints/ParticipantValidator.php` has no regex/legacy-format handling — only numeric range checks. This plan has not been acted on.
|
|
|
|
## 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.
|