fix(billing): validate Record Payment Amount and Invoice ID fields #221
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/mapps-215-record-payment-field-validation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Record Payment modal accepted a negative or zero Amount (creating a negative payment), inherited the browser's default step=1 so it rejected cents, and silently dropped a malformed Invoice ID (recording an unintended unapplied payment). Reference Number and Notes had no client length cap.
Amount now carries min="0.01" and step="0.01" so the browser rejects non-positive and sub-cent values, and submit-time validation re-checks for a positive, at-most-two-decimal, in-range number with a field-level message. Invoice ID is validated as a UUID (blank still means an unapplied payment) and its existence is confirmed via GET /invoices/{id} before recording, surfacing a field message instead of an opaque server FK error. Reference Number and Notes gain maxlength caps mirroring the server columns.
Payment Date is already bounded by the shared DateField (2000-01-01..2100-12-31, MAPPS-204), so it needs no change.
#MAPPS-215
The Record Payment modal accepted a negative or zero Amount (creating a negative payment), inherited the browser's default step=1 so it rejected cents, and silently dropped a malformed Invoice ID (recording an unintended unapplied payment). Reference Number and Notes had no client length cap. Amount now carries min="0.01" and step="0.01" so the browser rejects non-positive and sub-cent values, and submit-time validation re-checks for a positive, at-most-two-decimal, in-range number with a field-level message. Invoice ID is validated as a UUID (blank still means an unapplied payment) and its existence is confirmed via GET /invoices/{id} before recording, surfacing a field message instead of an opaque server FK error. Reference Number and Notes gain maxlength caps mirroring the server columns. Payment Date is already bounded by the shared DateField (2000-01-01..2100-12-31, MAPPS-204), so it needs no change. #MAPPS-215