fix(tms): validate worker PTO and move creation from REST to GraphQL - #567
fix(tms): validate worker PTO and move creation from REST to GraphQL#567emoss08 wants to merge 3 commits into
Conversation
workerptoservice.Create carried a TODO instead of validation, and the REST POST /worker-pto/ handler binds the request body straight into the entity, so a PTO row could be created with no worker, an empty reason, or an end date at or before its start date. Create now runs the domain Validate and returns the field-level MultiError before touching the repository. The driver-portal path already validated before calling Create, so it is unaffected. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015houJkqb8SuqPW4YpLoWCq
Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015houJkqb8SuqPW4YpLoWCq
POST /worker-pto/ bound the request body straight into the entity, which let a caller with create permission set any status — including Approved, skipping the approval flow and its notifications. The endpoint is gone; creation now goes through a createWorkerPTO GraphQL mutation whose input carries only workerId, type, dates, and reason, with the resolver forcing status to Requested and tenant scoping from the auth context, so every PTO enters the approval workflow. Client side adds the CreateWorkerPto operation and a createWorkerPTO wrapper beside the existing approve/reject mutations, and regenerates the GraphQL artifacts. No UI called the removed REST endpoint, and the OpenAPI spec never documented it, so nothing else changes. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015houJkqb8SuqPW4YpLoWCq
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
trenova-dash | b146f1b | Aug 31 2026, 10:23 PM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
trenova | b146f1b | Aug 31 2026, 10:23 PM |
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: ⛔ Files ignored due to path filters (5)
📒 Files selected for processing (10)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Standing down on the Workers Builds failures (trenova, trenova-dash): although this PR touches client code, the same deploy checks have failed identically on every recent commit regardless of content — including Go-only PRs #557–#566 and master merges — so this is the pre-existing environment issue, not this diff. Locally, Generated by Claude Code |
2 participants
Description
Two related fixes to the worker PTO create path:
Validation —
workerptoservice.Createcarried a// TODO: Validate PTO dataand the REST handler bound the request body straight into the entity, so a PTO row could be created with no worker, an empty reason, or an end date at or before its start.Createnow runs the domainValidateand returns the field-levelMultiErrorbefore touching the repository. The driver-portal path (RequestMyPTO) already validated before callingCreate, so it is unaffected.REST → GraphQL — even with validation,
POST /worker-pto/let a caller with create permission set any valid status, includingApproved— skipping the approval flow and its notifications. The endpoint is removed; creation is now acreateWorkerPTOmutation whose input carries onlyworkerId,type,startDate,endDate, andreason. The resolver forcesStatus: Requestedand takes tenant scoping from the auth context, so every PTO enters the approval workflow. The client gains theCreateWorkerPtooperation and acreateWorkerPTOwrapper beside the existing approve/reject mutations.No UI called the removed REST endpoint, and the OpenAPI spec never documented it (the handler had no swagger annotations), so nothing else changes.
Related Issue or Discussion
Follow-up from the codebase audit driving PRs #557–#564; the REST→GraphQL move was requested by the maintainer after the status hole was flagged.
Type of Change
Scope
services/tms/internal/core/services/workerptoservice/— validation gate inCreate+ new service testsservices/tms/internal/api/graphql/schema/worker.graphqls—CreateWorkerPTOInput+createWorkerPTOmutation; regeneratedgenerated/,gqlmodel/, resolver stubservices/tms/internal/api/graphql/resolver/worker.resolvers.go—CreateWorkerPtoresolverservices/tms/internal/api/handlers/workerptohandler/handler.go— REST create route and handler removedclient/packages/graphql/—CreateWorkerPtooperation + regenerated artifacts (schema, persisted documents, operation catalog)client/apps/web/src/lib/graphql/worker-mutations.ts—createWorkerPTOwrapperValidation
cd services/tms && go build ./... && go vet ./internal/api/...andgo test ./internal/api/... ./internal/core/services/workerptoservice/— all passgo run github.com/99designs/gqlgen generateandpnpm --filter @trenova/graphql codegenrun to parity with CI's codegen checkspnpm --filter @trenova/graphql typecheck && pnpm --filter @trenova/web typecheck— clean;pnpm --filter @trenova/web lintshows only pre-existing warnings in unrelated filesDeployment Notes
Breaking for any external API client that POSTed
/worker-pto/directly: creation must now go through thecreateWorkerPTOGraphQL mutation, and creating pre-approved PTO is no longer possible — every request enters the approval flow asRequested. No migrations or config changes.Checklist
AGENTS.md,CLAUDE.md, and existing repository patterns.🤖 Generated with Claude Code
https://claude.ai/code/session_015houJkqb8SuqPW4YpLoWCq
Generated by Claude Code