root
b99e8d0be4
Build & Push / Pipeline Tests (push) Successful in 1m59s
Test / Type Check (all packages) (push) Successful in 52s
Build & Push / Build & Push Docker Image (push) Successful in 3m40s
Test / API Unit Tests (push) Successful in 1m12s
Test / Homepage Unit Tests (push) Successful in 44s
Test / Carplace Unit Tests (push) Successful in 42s
Test / Admin Unit Tests (push) Successful in 43s
Test / Dashboard Unit Tests (push) Successful in 43s
Test / API Integration Tests (push) Successful in 1m8s
57 lines
4.3 KiB
Markdown
57 lines
4.3 KiB
Markdown
# Task: Add Input Validation for User Data Form
|
||
|
||
## Objective
|
||
Add length/format/range validation for the fields listed below, enforced at three layers: frontend (UX), backend (source of truth), and database (last line of defense). Do not change unrelated form behavior, styling, or fields not listed here.
|
||
|
||
## Scope
|
||
Only touch the files responsible for these fields: the form component(s), the API endpoint(s) that receive this data, the validation schema/middleware, and the DB migration/schema for these columns. If a field doesn't exist yet in the DB/API, flag it and ask before creating new schema — don't assume the shape.
|
||
|
||
---
|
||
|
||
## Field Rules
|
||
|
||
| Field | Type | Rule |
|
||
|---|---|---|
|
||
| firstName | string | required, trim, 1–50 chars, Unicode letters/spaces/hyphens/apostrophes allowed |
|
||
| lastName | string | required, trim, 1–50 chars, same charset as firstName |
|
||
| email | string | required, trim, max 254 chars, valid email format (use an existing validation library, don't hand-roll regex) |
|
||
| nationality | enum | required, must be a valid ISO 3166-1 country code (dropdown-backed, not free text) |
|
||
| phoneNumber | string | required, normalize to E.164 on save (use existing phone validation lib if the project has one; otherwise ask before adding a dependency), max 20 raw input chars |
|
||
| driverLicense | string | optional unless told otherwise, trim, 5–30 chars, alphanumeric only |
|
||
| date (generic) | date | must be a valid ISO 8601 date (`YYYY-MM-DD`); reject free text |
|
||
| address | string | required, trim, 1–255 chars |
|
||
| idPassport | string | required, trim, 5–30 chars, alphanumeric |
|
||
| country | enum | required, valid ISO 3166-1 country code (dropdown-backed) |
|
||
| issuedDate | date | required, ISO 8601, must be ≤ today |
|
||
| expirationDate | date | required, ISO 8601, must be ≥ issuedDate |
|
||
| dateTime | datetime | required, store as ISO 8601 with UTC offset — do not store naive local time |
|
||
| vinNumber | string | required, exactly 17 chars, alphanumeric excluding I/O/Q, uppercase |
|
||
| city | string | required, trim, 1–85 chars |
|
||
| amount | number | required, numeric, > 0, max 2 decimal places, reasonable upper bound (ask what "reasonable" means for this use case if not obvious from context — don't guess a business rule) |
|
||
|
||
## Cross-field rules
|
||
- `expirationDate` must be after `issuedDate`.
|
||
- `issuedDate` must not be in the future.
|
||
- Do not implement any cross-field rule not listed here without asking first.
|
||
|
||
---
|
||
|
||
## Implementation steps
|
||
|
||
1. **Locate existing validation approach.** Check if the project already uses a validation library (Zod, Yup, Joi, class-validator, pydantic, etc.) or a pattern for form validation. Use whatever already exists — do not introduce a new validation library if one is already in use.
|
||
2. **Frontend:** add `maxlength`/type-appropriate input constraints and inline error messages matching the rules above. Reuse existing form error-display patterns in the codebase.
|
||
3. **Backend:** add/extend the validation schema or middleware for the relevant endpoint(s) to enforce the same rules server-side. This is the authoritative check — assume the frontend check can be bypassed.
|
||
4. **Database:** only if column definitions currently allow unbounded/incorrect lengths, add matching length constraints via migration. Do not touch unrelated columns or tables.
|
||
5. Normalize country/nationality to ISO codes, phone to E.164, and dates to ISO 8601 at the point of validation/save — not scattered across multiple layers.
|
||
|
||
## Explicitly out of scope (ask before doing any of this)
|
||
- Adding a new third-party validation/phone/country-list library if one doesn't already exist in the project.
|
||
- Changing the DB schema shape (splitting address into multiple columns, etc.) — flag it as a suggestion instead.
|
||
- Any field not in the list above.
|
||
- Deep format validation for driverLicense/idPassport beyond length + charset (these vary too much by issuing country to hardcode safely) — ask if stricter per-country validation is actually wanted.
|
||
|
||
## Validation before reporting done
|
||
- Confirm each rule above has a corresponding check in frontend AND backend (list them field by field in your report).
|
||
- Confirm existing tests still pass; add new tests only for the fields touched here.
|
||
- Report any field where the existing DB column type/length conflicts with the rule above, rather than silently changing it.
|