psa-systems/mokosh-server
Watch
9
0
Fork
You've already forked mokosh-server
 1
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions

fix(billing): widen tax_rates.rate and validate the percentage range #281

Merged
vas2000-work merged 1 commit from fix/pms-339-tax-rate-column-width-and-validation into main 2026-06-16 23:49:40 +02:00
Conversation 0 Commits 1 Files changed 3 +69
David commented 2026-06-16 19:07:54 +02:00
Owner
Copy link

A tax rate is stored as the percentage as-typed (e.g. 20 for 20%), but the column was DECIMAL(5, 4) (max magnitude 9.9999), so any rate >= 10 overflowed and surfaced as an opaque 500 DATABASE_ERROR. A 10% GST, a 20% VAT, and any US combined rate at or above 10% could not be saved at all.

Migration 051 widens tax_rates.rate to DECIMAL(7, 4) (max 999.9999), a straight widening that preserves every existing row and keeps 4 decimal places of sub-percent precision. A new validate_tax_rate validator (mirroring the budget/SLA validators) requires 0 <= rate <= 100 with at most 4 decimal places and is wired onto UpsertTaxRateRequest.rate, so an out-of-range or negative value now returns a clean 422 field error instead of reaching the DB and dying there.

#PMS-339

A tax rate is stored as the percentage as-typed (e.g. 20 for 20%), but the column was DECIMAL(5, 4) (max magnitude 9.9999), so any rate >= 10 overflowed and surfaced as an opaque 500 DATABASE_ERROR. A 10% GST, a 20% VAT, and any US combined rate at or above 10% could not be saved at all. Migration 051 widens tax_rates.rate to DECIMAL(7, 4) (max 999.9999), a straight widening that preserves every existing row and keeps 4 decimal places of sub-percent precision. A new validate_tax_rate validator (mirroring the budget/SLA validators) requires 0 <= rate <= 100 with at most 4 decimal places and is wired onto UpsertTaxRateRequest.rate, so an out-of-range or negative value now returns a clean 422 field error instead of reaching the DB and dying there. #PMS-339
fix(billing): widen tax_rates.rate and validate the percentage range
All checks were successful
E2E / Playwright against staging (pull_request) Successful in 1m9s
Details
Check / fmt + clippy + compile + unit/doc tests (pull_request) Successful in 3m22s
Details
Integration / integration tests (pull_request) Successful in 7m37s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
e70560c31b 
A tax rate is stored as the percentage as-typed (e.g. 20 for 20%), but the column was DECIMAL(5, 4) (max magnitude 9.9999), so any rate >= 10 overflowed and surfaced as an opaque 500 DATABASE_ERROR. A 10% GST, a 20% VAT, and any US combined rate at or above 10% could not be saved at all.

Migration 051 widens tax_rates.rate to DECIMAL(7, 4) (max 999.9999), a straight widening that preserves every existing row and keeps 4 decimal places of sub-percent precision. A new validate_tax_rate validator (mirroring the budget/SLA validators) requires 0 <= rate <= 100 with at most 4 decimal places and is wired onto UpsertTaxRateRequest.rate, so an out-of-range or negative value now returns a clean 422 field error instead of reaching the DB and dying there.

#PMS-339
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-server!281
No description provided.