- createRequestSchema now requires employee_id to be a UUID-format
string (was a free-text non-empty check), matching the new FK to
Employee in schema.prisma.
- createRequest() now returns a CreateRequestResult discriminated
union and catches Prisma P2003 (FK violation), returning a friendly
ok:false error instead of a raw 500 when employee_id does not
reference an existing Employee. POST /api/requests branches on
created.ok and returns 400 in that case.
- tests/requests.test.ts: every test that used to POST a fake string
employee_id (emp-1, emp-2) now creates a real Employee first via
createTestEmployee() and uses its id, since employee_id is now a
real FK. Added coverage for a syntactically invalid UUID and for a
well-formed but non-existent UUID (expects the friendly 400 from
the P2003 catch, not a raw 500) - the exact case this retrofit was
meant to protect against.
POST/GET /api/employees, same thin-route pattern as
src/app/api/requests/route.ts including the auth() 401 check
(middleware.ts excludes /api from page-route gating). POST also
surfaces createEmployee()'s FK-violation translation (nonexistent
managerId) as a 400, not a raw 500.
Mirrors src/lib/requests.ts's shape: Zod schema, ValidationResult
discriminated union, CRUD via Prisma, toRecord() camelCase->snake_case
mapping. managerId is only format-checked as a UUID here; a
nonexistent managerId is caught via Prisma's P2003 FK-violation error
in createEmployee() and translated into a friendly {ok:false,error}
instead of leaking a raw Prisma error.
GET and POST both call auth() first and return 401 { error:
Unauthorized } when there is no session, before doing any
validation or DB work. This is the API-side half of route-gating -
middleware.ts handles page routes but deliberately excludes /api,
so API routes verify the session themselves.
Flat permission model only (per CLAUDE.md): this checks logged-in
or not, nothing more granular. No role/permission logic added.
middleware.ts gates page routes by default (redirect to /login when
unauthenticated), except /login itself and Next.js internal asset
paths - config.matcher excludes /api entirely, /_next/static,
/_next/image, and favicon.ico. Default-deny: everything requires login
unless explicitly excluded, including the home page, rather than an
opt-in allowlist new routes could forget to join.
Builds its own lightweight NextAuth instance from auth.config.ts
(no Credentials provider) instead of importing auth from auth.ts, to
stay Edge-Runtime compatible - see auth.config.ts.
API routes are deliberately NOT gated here (config.matcher excludes
/api). Auth.js guidance is to verify the session as close to the data
fetching as possible rather than rely on middleware alone; API route
auth is added directly in each route handler instead (next commit).
This project pins Next.js 14.2.35, which predates the Next.js 16
middleware.ts -> proxy.ts rename, so this stays middleware.ts with a
default export, not proxy.ts.
auth.config.ts holds only the Edge-Runtime-safe parts of the Auth.js
config (session strategy, pages, jwt/session callbacks) with an empty
providers array. auth.ts spreads it and adds the real Credentials
provider on top for use in API routes/Server Components (Node runtime).
Needed for middleware.ts (next commit): the Credentials provider's
authorize() pulls in bcryptjs via verifyUserCredentials(), which is a
Node API not supported on the Edge Runtime that middleware.ts runs on.
Without this split, next build bundles bcryptjs/jose into the Edge
middleware chunk and warns; with it, the build is clean.
toanhoang
toanhoang