myep/docs/body-dimensions-transition-plan.md

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.