An inspection report mirrored its outcome onto the inventory item but
never touched the item's status, and the loading paths gated on status
alone. Cargo that passed, reached READY_FOR_LOADING and was then
re-inspected as FAILED kept that status and loaded anyway.
Gate loading on the inspection outcome. load() is the single choke point
every loading path runs through, including loadItemsOntoTrain, so the
check sits there: nothing but PASSED travels, and the message names the
outcome so the operator knows what to fix.
A failed or under-review re-inspection also pulls the cargo back out of
the ready queue. load() refuses it either way, but leaving it READY_FOR_*
would keep it on the loading and pickup lists as though nothing had
happened.
Reversing a held inspection now needs a reason. Passing cargo whose
current inspection is FAILED or NEEDS_REVIEW is rejected without remarks,
so the record says why cargo that was deliberately held may now travel.
A first-time pass is unaffected.
Mark Selected as Inspected skips failed and under-review items instead of
clearing them. Overturning a failure is a deliberate, reasoned act, never
a side effect of ticking a row in a list; those items are reported back
with a reason telling the operator to re-inspect them individually.
Verified: freight-api type-check passes; 15 warehouse suites pass
(90 tests, 12 of them new).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Marking a received item inspected advanced only the rows the operator
ticked. A booking's cargo spans one inventory row per container, and a
multi-truck arrival files a GRN batch per truck, so a six-container
booking stayed half-inspected and never reached Ready To Load.
Widen the selection to every still-inspectable row of the same booking
before inspecting. Each row is then passed and advanced exactly as
before — EXPORT to READY_FOR_LOADING, IMPORT to READY_FOR_PICKUP — so
the whole booking moves together.
The rows the operator actually ticked lead the response, and are kept
even when ineligible so their skip reason still surfaces rather than
being dropped silently. Rows already PASSED, rows in a status that
cannot be inspected, and rows belonging to another booking are left
alone. Ad-hoc inventory with no booking expands to itself.
Also show yards by name in the receive and received queues. They
selected yards.code, so the route column read KALITY, the internal code
for the yard everyone calls GMP / Gelan Multipurpose Port.
Verified: freight-api type-check passes; both new SQL statements
EXPLAIN-validated against the dev database; 14 warehouse suites pass
(78 tests, 5 of them new).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The receive drawer captured one truck per arrival, so a customer whose
containers came on three trucks had to be received three times over.
Stage trucks instead. "Add another truck" validates the form exactly as a
single-truck receive does, files the truck with its own plate, driver and
containers, and clears the form for the next one. The staged trucks are
listed above the form with their boxes, each removable, and the arrival is
received in one operation.
Containers already staged on an earlier truck drop out of the picker, so
the same box cannot be sent twice.
Receiving with a part-filled form and trucks already staged is treated as
the operator still typing rather than a finished arrival: it asks them to
finish or clear the truck instead of silently dropping what they entered.
An untouched form receives just the staged trucks.
With no trucks staged the drawer sends the original truckEntrance and
containerNumbers fields, so a single-truck arrival takes exactly the path
it did before.
Verified: backoffice type-check reports 982 errors both with and without
this change (all pre-existing, none in the touched files); 13 warehouse
API suites pass (73 tests).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`findAll` selected `r.*` in raw SQL. `dataSource.query` bypasses the entity
mapping, so rows came back under their database names — `container_numbers`,
`submitted_at`, `quoted_total_amount` — while both clients read camelCase.
Every field on the row was undefined; the backoffice queue crashed on
`containerNumbers.join(", ")` and took the page down through the error
boundary.
Alias each column explicitly, the way `plannedReturns()` below it already
does, and cast the two numeric columns with `::float8` — raw SQL skips the
entity's numeric->Number transformer, which would otherwise hand the clients
strings. Type the result as `EmptyReturnRequestRow` so the signature matches
what the projection actually selects rather than claiming absent fields.
Guard the three `containerNumbers.join(...)` call sites too, so one odd row
cannot white-screen the queue again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A customer's containers routinely arrive together on several trucks, but
bulk receive accepted one truck per operation: a single truckEntrance and
a flat containerNumbers list capped at two boxes. Receiving a six-container
arrival meant six separate operations.
Model the arrival as a list of trucks instead. Each entry carries its own
truckEntrance, its own containers and, optionally, its own bookingIds,
defaulting to the operation's. The receive loop iterates trucks, so every
per-truck invariant is preserved rather than pooled: the physical capacity
check (one 40ft or up to two 20ft), the container-to-plate assignment
check, the GRN batch number and the capacity assertions all still apply
per truck.
Callers sending the existing truckEntrance and containerNumbers fields
collapse to a one-element list and behave exactly as before.
Reject a container listed on more than one truck up front. The per-booking
check only catches this once a unit is marked received, so a duplicate
would otherwise surface from whichever truck happened to be processed
second and read as a duplicate gate entry rather than a data-entry slip.
Verified: freight-api type-check passes; all 13 warehouse suites pass
(73 tests).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operators know the yards by name, not by the internal code: the yard coded
KALITY is universally called GMP / Gelan Multipurpose Port (Indode), so
rendering the code alongside the name read as two different places.
Show the name alone in route creation, the yard desks modal and the
booking route card, falling back to the code only when a yard has no
name. The code is unchanged in the data and remains searchable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Implemented method in to allow customers to request an extension for expired contracts.
- Added component in for users to initiate extension requests.
- Updated to include logic for handling extension requests for expired contracts.
- Enhanced to display extension request options and status.
- Created migration to add and columns to the contracts table.
- Added unit tests for contract extension request and handling in .
- Defined DTOs for request and extension in .
- Updated types in to include new fields related to contract extensions.
- Added TrainCrewAssignment module with controller and service for managing crew assignments.
- Integrated TrainCrewAssignmentService into TrainSchedulingService to ensure crew readiness before train dispatch.
- Updated TrainScheduling module to include TrainCrewModule for dependency injection.
- Introduced new permissions for assigning train crew in freight permissions registry.
- Enhanced front-end ScheduleCrewPage to allow assignment of crew members to train schedules, including validation and UI for adding/removing drivers and support crew.
- Created trainCrewAssignment.service to handle API interactions for crew assignments.
- Introduced ScheduleCrewPage for assigning train crew to schedules.
- Updated routing in App.tsx to include crew assignment path.
- Enhanced TrainScheduleV2ListPage with a button to navigate to crew assignment.
- Added new chart components and styles for improved wagon performance reporting.
- Refactored existing styles and components for better visual feedback and usability.
Replace the icon-and-cards landing with a photographic hero that
alternates
between the Furi station and freight train photos, a single headline,
and two
compact glass cards that pin the background on hover. Below it: the
corridor
rail, one showcase mockup per portal (passenger trip search, freight
live
tracking), the existing stats and footer.
- Add the official EDR logo as transparent green/white PNGs (lockup and
mark),
used in the header, footer and favicon
- Switch to Plus Jakarta Sans and a palette keyed to the logo green
- Split the page into components under src/components
- Header links: Passenger, Freight, Publications
- Added DTOs for creating, querying, and updating train crew members.
- Created entity for train crew members with relevant fields and enums for role, nationality, and status.
- Developed service for handling CRUD operations and ensuring no duplicate crew members.
- Implemented controller to manage API endpoints for train crew operations.
- Integrated permissions for viewing, creating, updating, and deleting train crew members.
- Added frontend components for displaying, adding, editing, and deleting train crew members.
- Established API service for interacting with the train crew backend.
- Updated routing and sidebar to include train crew management section.
edrsc.com had no entry point — a visitor could not tell which of the two
apps they wanted. This adds @edr/landing: one static page whose job is to
make that choice obvious, with the two doors above the fold and the rest
kept to supporting context.
Fills in apps/edr-landing/, which until now held an orphaned next-env.d.ts
from an abandoned Next 15 start and was built by nothing.
- Next.js 14 static export. Versions mirror the passenger portal exactly,
so they resolve to what the lockfile already had and add 6 packages.
Depends on no workspace package — @edr/ui-common's Tailwind 4 tokens do
not fit this Tailwind 3 setup.
- Destinations come from NEXT_PUBLIC_PASSENGER_URL / NEXT_PUBLIC_FREIGHT_URL
as origins, with the entry path appended in src/lib/apps.ts. Freight links
to /portal rather than /, which is that app's own marketing landing.
- Design lifted from EDRFreightLandingPage so the two public surfaces read
as one railway. Figures (752 km, ~16 h) are the ones freight already
asserts publicly.
- Fonts load as a stylesheet, not next/font: next/font fetches from
fonts.googleapis.com during `next build` and failed the build outright on
a machine without network. Verified deterministic over repeated builds.
- CountUp renders its final value server-side and the reveal animation's
hidden state is scoped behind html.js, so the page is complete with
JavaScript off instead of blank.
turbo.json: a static export's artifact is out/, which the build task did not
list — a cache hit would have restored a build with the artifact missing.
Also gitignored.
Dockerfile.web: passes the two NEXT_PUBLIC_* build args through (a static
export inlines them at build time, so runtime env does nothing), and exempts
this app from the VITE_* required-check that guards the freight Vite apps and
would otherwise fail its build.
Claude-Session: https://claude.ai/code/session_011ZMMHwK4Ham1Dt19FVZQj3
dev independently added 3850000000000-Publications.ts. Renumbered the
DJF branch's own 3850000000000-ExchangeSettingsPerCurrency.ts to the
next free slot (3880000000000, above this branch's other new
migrations) per the project's unique-timestamp rule. Unpushed and
un-shared, so a rename is safe here — updated the class name/name
property to match, and the already-applied local dev DB's recorded
migration row.
Claude-Session: https://claude.ai/code/session_01CZy77vCWhka3pnmVF9NDkL
