Files
summercms/.planning/todos/done/lagoon-validate-min-message.md
Jakub Zych 1bdbdf041b docs(12-01): reword the Phase 12-14 scope and requirements
- Phase 12 criteria 1-3 and goal: realtime/channels, owner-only share,
  cover import, re-gated search total (D-03, D-04, D-06, D-19, D-20)
- reservations and anonymous public-token views move to Phase 13
  (API-03, API-07); the Discogs cover-price route to Phase 14 (INTG-01)
- the folded lagoon-validate-min-message todo moves to done
2026-10-02 11:44:52 +02:00

13 lines
1.1 KiB
Markdown

---
title: lagoon.Validate reports every numeric range failure with the max message
date: 2026-09-30
priority: medium
area: summercms.go lagoon
---
When a field has `integer` or `numeric` and a `min`, `max` or `between` rule, `lagoon.Validate` checks the range once and always answers a failure with the `max` message. With only `min:0` and a value of `-1`, the message is `The views may not be greater than .`: the wrong rule and an empty parameter. Laravel answers `The views must be at least 0.` for `min` and `The views must be between 0 and 10.` for a numeric `between`.
Found while writing `docs/database/casts-and-validation.md` (Phase 11.1 plan 04). The page does not show a `min` failure; its example uses `max:1000`, whose message is correct.
Suggested fix: in `modules/lagoon/validate.go`, pick the message by which bound failed (`min` below the lower bound, `max` above the upper, `between` when both bounds came from `between`), with a unit test per case. Check the PHP API responses first if a ported endpoint depends on the current text. The change is outside the docs phase boundary, so it is not made in Phase 11.1.