test(projects): pin oversized-budget 422 and company-id injection safety #283

Merged

vas2000-work merged 1 commit from fix/pms-316-project-budget-oversize-and-safe-company-tests into main

2026-06-16 23:51:49 +02:00

David commented

2026-06-16 20:02:15 +02:00

Owner

PMS-324 already added the request-layer budget validators (validate_budget_amount / validate_budget_hours) and numeric-budget deserialization, so an oversized Budget Amount or Budget Hours is rejected with a controlled 422 instead of the 500 numeric-overflow / raw deserialization 422 the issue reports. The end-to-end suite, however, only exercised the negative / over-precise / non-numeric cases, never the over-the-column-limit boundary, and nothing pinned that a SQL-injection-shaped company value cannot reach the parameterized query.

This adds project_oversized_budget_and_safe_company_id, covering the PMS-316 acceptance criteria that were not yet guarded: budgets at the DECIMAL column maxima create cleanly, a budget_amount above DECIMAL(12, 2) and a budget_hours above DECIMAL(10, 2) each return 422 (not 500) on the create path, a non-UUID company_id (ZQA'); DROP TABLE companies;--) is rejected at request extraction because the field is a typed Option, and a normal create against the real company id still succeeds afterward (the companies table is intact). Frontend field-level validation and the form max-value constraints live in the mokosh-apps repo and are out of scope for this backend change.

#PMS-316

PMS-324 already added the request-layer budget validators (`validate_budget_amount` / `validate_budget_hours`) and numeric-budget deserialization, so an oversized Budget Amount or Budget Hours is rejected with a controlled 422 instead of the 500 numeric-overflow / raw deserialization 422 the issue reports. The end-to-end suite, however, only exercised the negative / over-precise / non-numeric cases, never the over-the-column-limit boundary, and nothing pinned that a SQL-injection-shaped company value cannot reach the parameterized query. This adds `project_oversized_budget_and_safe_company_id`, covering the PMS-316 acceptance criteria that were not yet guarded: budgets at the DECIMAL column maxima create cleanly, a budget_amount above DECIMAL(12, 2) and a budget_hours above DECIMAL(10, 2) each return 422 (not 500) on the create path, a non-UUID company_id (`ZQA'); DROP TABLE companies;--`) is rejected at request extraction because the field is a typed Option<Uuid>, and a normal create against the real company id still succeeds afterward (the companies table is intact). Frontend field-level validation and the form max-value constraints live in the mokosh-apps repo and are out of scope for this backend change. #PMS-316

David added 1 commit

2026-06-16 20:02:15 +02:00

test(projects): pin oversized-budget 422 and company-id injection safety

E2E / Playwright against staging (pull_request) Successful in 1m38s

Details

Check / fmt + clippy + compile + unit/doc tests (pull_request) Successful in 2m54s

Details

Integration / integration tests (pull_request) Successful in 6m37s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

7b2370dd88

PMS-324 already added the request-layer budget validators (`validate_budget_amount` / `validate_budget_hours`) and numeric-budget deserialization, so an oversized Budget Amount or Budget Hours is rejected with a controlled 422 instead of the 500 numeric-overflow / raw deserialization 422 the issue reports. The end-to-end suite, however, only exercised the negative / over-precise / non-numeric cases, never the over-the-column-limit boundary, and nothing pinned that a SQL-injection-shaped company value cannot reach the parameterized query.

This adds `project_oversized_budget_and_safe_company_id`, covering the PMS-316 acceptance criteria that were not yet guarded: budgets at the DECIMAL column maxima create cleanly, a budget_amount above DECIMAL(12, 2) and a budget_hours above DECIMAL(10, 2) each return 422 (not 500) on the create path, a non-UUID company_id (`ZQA'); DROP TABLE companies;--`) is rejected at request extraction because the field is a typed Option<Uuid>, and a normal create against the real company id still succeeds afterward (the companies table is intact). Frontend field-level validation and the form max-value constraints live in the mokosh-apps repo and are out of scope for this backend change.

#PMS-316