List + inline edit (model within category, area, assignee, specs, asset tag, serial number) + delete. No create form -- creation only happens via the bot.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
GET /api/areas, GET /api/inventory-scans, PATCH+DELETE /api/inventory-scans/[id], GET /api/inventory-scans/[id]/photo (proxies Telegram file_id on demand, derives Content-Type from file_path extension since Telegram serves application/octet-stream regardless of actual type).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auth via BOT_INGEST_SECRET bearer header (src/lib/bot-auth.ts), not Auth.js session -- caller is the inventory-capture Telegram bot service, not a browser.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Per-row employee <Select> + Transfer button alongside the existing Return
button, shown for active (returned_at null) rows. PATCHes
/api/assignments/[id] with {employeeId}, which the route already dispatches
to transferAssignment() vs returnAssignment() based on body shape.
Mirrors assignments/page.tsx's per-row close mini-form pattern; targetStatus
select reuses the closed AssetItemStatus set client-side, same precedent as
licenses page's licenseType select.
createMaintenanceRecord()'s AssetItem status guard pinned status:{not:"retired"}
instead of status:"in_stock", so two concurrent opens (or an open racing a
concurrent createAssignment()) could both pass the guard, producing two open
MaintenanceRecords or an orphaned active Assignment. Guard now pins "in_stock"
exactly, mirroring createAssignment()'s own atomic guard.
closeMaintenanceRecord()'s targetStatus accepted any of the 4 AssetItemStatus
values, including "assigned" — which sets AssetItem.status without creating a
corresponding Assignment row, desyncing Assignment (source of truth for who
holds what) from AssetItem.status with no way back. Restricted to
in_stock|retired, the only two outcomes a closed repair can actually resolve
to.
createMaintenanceRecord() opens a record and flips AssetItem.status to
"repair" inside one transaction, rejecting on missing/retired AssetItem,
an active Assignment, or an already-open record for the same item.
closeMaintenanceRecord() sets endDate/resolutionNotes and applies a
caller-supplied targetStatus (never defaulted) to the AssetItem, guarding
double-close and endDate>=startDate. Mirrors src/lib/assignments.ts's
Zod-validate + $transaction + WHERE-guarded updateMany race-closing pattern.
The only way to move an Assignment to a new employee was two separate calls
(PATCH return + POST create), which is not atomic and left a race window
where a third party could grab the now-in_stock AssetItem in between, plus
no rollback if the second call failed. Adds transferAssignment() which
closes the old Assignment and creates the new one inside a single
prisma.$transaction(), per docs/asset-license-management.md's "Assignment
(chốt 2026-08-02)" spec. Does not touch AssetItem.status or
License.seatsUsed — the resource never becomes free mid-transfer. Wired
into PATCH /api/assignments/[id]: an employeeId key in the body dispatches
to transfer, a returnedAt key to return, both together is rejected as
mutually exclusive.
POST/GET /api/assignments mirror the existing entity route pattern
(auth-gated, thin handler delegating to src/lib/assignments.ts). PATCH
/api/assignments/[id] is the first dynamic-segment route in the codebase,
per the stakeholder-confirmed convention (docs/asset-license-management.md)
of update routes being PATCH /api/<entity>/[id] rather than an
action-based sub-route.
createAssignment() enforces the XOR (assetItemId/licenseId) at the Zod
layer and the AssetItem.status/License.seatsUsed business rules inside a
single prisma.$transaction(), using atomic WHERE-guarded updateMany() calls
(not plain read-then-write) to close the seat-overbooking and
double-assignment race conditions flagged for License by code-reviewer.
returnAssignment() reverses those side-effects the same way and closes the
double-return race with the same pattern.
AssetItem.model was a free-text string with no referential integrity.
Now a required FK to AssetModel, mirroring the Request.employeeId and
License.vendorId retrofit precedent (no backfill needed, no real
AssetItem data existed).
Zod schema + validate function, Prisma-backed CRUD following the
{ok,value}|{ok,error} pattern from the start. createAssetCategoryAttributeDef()
catches P2002 for the composite (categoryId, key) unique constraint (mirrors
createAssetItem()'s serialNumber handling) and P2003 for the categoryId FK
(mirrors createPurchaseOrder()).
Nullable FK from License to PurchaseOrder for supply-side traceability
(which PO a license came in through), mirroring AssetItem.purchaseOrderId's
just-merged pattern exactly. Separate commit from the earlier
License.vendorId retrofit per the project's 1-commit-per-business-change
convention.
License.vendor (free-text string) is now vendorId, a required FK to
Vendor, per docs/asset-license-management.md's "## Vendor (chốt
2026-08-02)" spec. Mirrors the Request.employeeId string->FK precedent:
Zod validates UUID format only, Prisma's own FK constraint (P2003) is
caught at insert time and translated into a clean 400 instead of a raw
500. No License data existed yet, so this is a pure column-type
migration, no backfill needed.
Also converts createLicense() to the {ok,value}|{ok,error} result
pattern used elsewhere (createRequest, createAssetItem) instead of
returning a bare LicenseRecord promise - closes the gap flagged in
CLAUDE.md now that License has its first FK-violation error case to
handle.
- 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