- Implemented for Excel download of wagon performance report sections, including column width adjustment and timestamped filenames.
- Created to compute derived wagon performance figures based on movements and status logs, ensuring consistency with API data.
- Enhanced with new fields for tracking last movement and statistics window days for improved reporting capabilities.
- Implemented BookingWagonsPanel to show allocated wagons, their containers, and export functionality.
- Integrated the new panel into BookingRequestDetailPage and BookingRequestsPage.
- Enhanced wagon cancellation modal to support rebooking of wagon cancellations with partner units.
- Updated API service to include a method for downloading wagons workbook.
- Modified types and constants to accommodate new features related to wagons.
- Adjusted various components and pages to ensure compatibility with the new wagon-related functionality.
Ready to Load listed inventory and offered an auto-load picker, but the
warehouse floor works train by train: a train stands at the yard, its
bookings board wagon by wagon, it rolls. That view existed only on the
train schedule workspace, which the warehouse staff do not run.
Ready to Load now has an Items / By train switch. By train is a mirror
of the schedule's own column, placed where the loading actually happens.
Nothing in it has its own rules. Train position, the per-yard loading and
unloading windows, and the per-booking Load / Wagons / Unload actions all
come from the train-scheduling endpoints the schedule workspace already
calls, so a Load that would be refused there is disabled here with the
same reason and the two surfaces cannot disagree. No train-scheduling
code is touched.
What the warehouse adds is what the schedule cannot see: which of the
train's bookings are physically in the shed, with their GRN and
inspection state, laid out along the flow the staff follow -- receive and
GRN, inspect, ready, open the loading window, train at yard, load per
wagon, dispatch, unload at port.
Wagons
- The wagon modal calls the same per-wagon journey endpoints, so every
server gate (train at the yard, window started, PAID, GRN) is the
schedule's own.
- Wagons go one at a time in order: the server flips the booking to
IN_TRANSIT or ARRIVED on whichever call clears the last wagon, so
sequential is required, not merely tidy. A failure stops the run, the
wagons already sent stay done, and the toast says how many, so a retry
only resends the rest.
- Deliberately not mirrored: cancelling wagons that will not ride, and
the direct truck-to-train handover. Both are commercial decisions
(fees, credits, GRN waiver) that belong to the schedule workspace.
loadable-trains takes includeDispatched. Loading follows the train after
it rolls, since a mid-corridor warehouse boards its cargo when the train
stands at its yard, and the train-centric view needs the same set the
schedule offers Load on. The default stays pre-dispatch only, so the
existing auto-load picker is unchanged.
Also fixes the backoffice build: ReceiveInventoryModal used MultiSelect
without importing it, left behind by the self-haul assignment work.
The customer truck card on the booking's Logistics tab is now usable for
every cargo type, with an Excel template and bulk upload that match what
the API enforces.
Excel template and bulk upload
- The template is built per booking. Container bookings get the booking's
own containers with their sizes on a reference sheet and sample rows
paired 20ft+20ft; bulk (PER_TON) bookings get a Planned Tons column;
counted cargo (PER_ITEM: machinery, RoRo vehicles) gets Planned Quantity.
- Parsing validates the whole file before anything is posted: plate,
driver, truck type, ISO container numbers, containers on the booking,
duplicates across rows, containers already on a truck, and the capacity
rule (one 40ft alone, or two 20ft). Errors quote the Excel row number.
- The bulk DTO reuses AddCustomerTruckDto instead of a drifted copy that
lacked plannedTons/plannedQuantity, so bulk cargo can be uploaded at all.
- A partial failure is reported per row in the modal instead of closing it
as if every truck had been created.
Capacity rule in the form
- The container picker shows sizes and stops offering a second container
once a 40ft is picked, or a 40ft once a 20ft is picked.
- PER_ITEM cargo commits by item count; tonnage becomes optional.
Shared vocabulary
- CUSTOMER_TRUCK_TYPES and ISO_CONTAINER_NUMBER move to @edr/types so the
API validators, the dropdown and the template read one list.
When assignment is open
- The card always renders and states why assignment is closed (EDR
haulage, unpaid, train not arrived, cargo already loaded) rather than
vanishing.
- Self-haul is blocked only once EDR has committed to the road leg: an
approved last-mile request or an existing last-mile leg. A delivery
address whose request is still awaiting confirmation, submitted or
rejected no longer blocks the customer from bringing their own truck.
Collection on exports has no approval step and still blocks as before.
Both the multi-truck service and the legacy single-truck path read the
same SQL fragment (edrHaulsThisBooking), and the portal applies the same
rule with a notice that assigning a truck makes the pending request
unapprovable. The last-mile side already refuses to approve a booking
carrying a customer truck, so the two paths stay mutually exclusive.
Verified: EXPLAIN on the new SQL against edr_dev, type-check clean for
freight-api and portal, 12 util specs pass (5 new). Backoffice type-check
fails only in pre-existing user-management files.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The menu item was gated on the brand-new empty_return_requests:view key,
which on the dev DB is held by one position (Operations Chief) — so the
Director and Dispatcher who already work Container Returns two rows above
it never saw the entry at all.
Viewing the queue now accepts that key OR warehouse_inventory:view, the
key the rest of the Imports menu runs on, in the sidebar, the route guard
and the API's read routes alike. Approving and rejecting stay on the
review key on their own, and the buttons come up disabled (with the
reason) for a viewer who lacks it rather than firing into a 403.
The dedicated keys are still there to hand out per position whenever
that call gets made.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Typing container numbers let a customer request a return for a box that
never came in on that booking — and gave them a blank field to guess at
when they did not have the numbers to hand.
The portal now lists the booking's own containers, minus any already
spoken for by a live request, as a tick list; the count follows the
ticks. The API backs that up: every submitted number must be one of the
booking's containers, and a booking with no container numbers recorded
says so instead of offering an empty form.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A booking sold WITHOUT the return service had no way to send its empties
back: the containers were the customer's problem and nothing in the
system priced, billed or planned the movement.
Adds the request flow end to end. The customer opens the booking, says
how many containers are coming back and types each number; the request
lands in a new backoffice queue (Empty Return Requests). Approval prices
it off the same live WITH_RETURN route rate the rule engine bills when
the service IS bought up front — per container, converted to birr, and
overridable by the reviewer — and issues the invoice there and then.
Payment settles through the normal invoice path, whose
`empty_return_request.invoice.paid` event moves the request to PAID; the
customer then books the return date and the truck.
Scheduled requests surface on Container Returns as Planned Empty
Returns, where confirming the arrival records the containers through the
existing empty-container-return flow — which in turn closes the request
once its last container is in.
Container freight only, never a booking that already ships WITH_RETURN,
and only from IN_TRANSIT onward: the empty comes back after delivery, so
the option has to outlive ARRIVED.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Container Returns only ever offered the last-mile path: a booking reached
the list once it had a truck assigned and warehouse inventory flagged as
returning. Bookings that ship WITH equipment return had no way in, so the
empties they owe were invisible until that path happened to fire.
Adds GET /import-operations/empty-return-bookings — the containers a
booking flagged is_return, carrying whichever of them already has an
empty return recorded, grouped one row per booking and dropped from the
list once nothing is pending. Covers both spellings of the booking's
equipment_return (WITH_RETURN and the older RETURN) and skips bookings
that never ship.
Backoffice grows a "Bookings With Empty Container Return" card above the
existing sections: pick the booking, tick the containers coming back,
say where they landed, and each tick becomes an empty container return
on that booking — which is what the Returned Containers table then
advances. The existing last-mile, standalone and bulk flows are
untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Added to manage decisions on partially loaded bookings during log-pass and dispatch actions.
- Enhanced to track and manage bookings left behind when a train departs a yard.
- Updated and to pass necessary station data for handling partially loaded bookings.
- Modified and to account for customer-fault fees and ensure proper handling of credits.
- Introduced fault tracking in interface to differentiate between customer and EDR faults.
Both apps wrote a cookie named `current-position-id` but stored
different ids in it — freight the `employeePositionId`, Smart Office the
`position.id`. On a shared domain each login overwrote the other's desk
selection, and the loser silently fell back to the first position.
Freight now uses `freight-current-position-id` through a small helper
that reads the old name once, so a session live across the deploy keeps
its desk, and clears it on every write.
Also mounts the position switcher in the freight dashboard header. It
only existed under /performance-management, so on every other page a
two-desk user had no way to switch and was stuck on whatever
`useAuthUser` defaulted to. It now hides below two positions rather than
showing a one-option dropdown to the single-desk majority.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Staff given a post in Smart Office and another in freight only ever
loaded one of them. Two causes, both in how the IAM guard collapses the
login snapshot:
- `x-current-position-id` is read two ways inside one function: the
employee row is matched on `position.id`, the position on
`employeePositionId`. Freight sends the latter, Smart Office the
former, so whichever value arrives one lookup matches nothing and
falls back to `positions[0]`. FreightJwtGuard now matches both fields.
- IAM keeps one employee row per organization, and EDR and EDR Freight
are separate organizations, so a user holding a post in each owns two
rows. Only the active row reached `collectPermissionKeys`, so the
freight post's permissions disappeared whenever the other row won the
active slot. `employee.positions` now unions every row, which is what
the util already does for the array shape.
`delegatedPositions` stays scoped to the active row on purpose: yard
scope widens on it, and someone standing in on another organization's
row is not this desk's stand-in.
/auth/me now returns every employee row, active row first, so the
position picker can offer a desk that is not on the active row.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DiffRow rendered onboarding's initial field values as '— → value',
implying a prior state that never existed. Show the value alone when
there is no real before.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Provisioning created nothing on dev. Synapse answers a burst of writes with
429 + retry_after_ms, and a reconcile is nothing but a burst of writes, so the
first throttled m.space.child PUT threw and took the whole run with it. On the
sign-in path ChatSsoService catches that by design, so every employee got a
working sign-in into an Element with no rooms in it. fetchWithRetry now sits
behind all three request wrappers and honours the delay Synapse asks for,
capped at 5 attempts so a wedged homeserver still fails rather than hangs.
Two ways the reconcile could destroy state, both now blocked:
- Zero position holders meant "remove everyone": every member kicked from
every room, then every account deactivated. It never means that - it means
the IAM query failed, the org/unit keys drifted, or a migration is
mid-flight. reconcile() aborts, and syncMembership() refuses to empty a
populated room, as a per-room backstop.
- Deactivation could not be undone here. Reactivation wants a password and
password_config.enabled is false, and room memberships do not come back.
Departed accounts are locked instead - same access block, one PUT to
reverse - and ensureUser lifts the lock when someone returns in IAM.
Also: join the space itself, not only the rooms inside it, or Element leaves
every dept room loose in Home and never shows the space at all. And drop the
bridge's per-type routing - it pointed at a hardcoded dept-operation alias
while the reconcile derives dept-${positionKey} from IAM, so bridged
notifications went to a room the bridge created and nobody was in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MoR's location master has no zone level in a chartered city: CITY_NAME is the
sub-city and LOCALITY_DESC is the numbered woreda. e-Trade fills the gap by
repeating the region in ZONE, pushing the sub-city into CITY_NAME and the
woreda number into LOCALITY_DESC, so every Addis Ababa buyer failed CITY_NAME
lookup and could not be filed at all.
Retry one level down when ZONE repeats the region, accepting it only when
both shifted levels resolve exactly — an unknown zone still fails with its own
message. Match a zero-padded 07 against MoR's own WOREDA 7 spelling, and
add the reviewed AMAHARA / KOLFIE KERANIYO / MISRAK SHOA aliases.
Verified against the dev database: 2 of 40 companies resolved before, 31 after.
Warehouse loading queues and the train schedule page now share one truth:
the schedule's per-yard stationWorkLogs. A booking's items aren't loadable
until "Start loading" has been clicked for their boarding yard, mirroring
the same assertStationWorkStarted check the train schedule page's own Load
button already enforces.
- LoadableTrainRow/LoadableTrain carry originStationId + stationWorkLogs.
- TrainLoadableItem carries originYardId/originYardLabel/loadingWindowStarted,
computed from station_work_logs in the same query.
- New YardLoadingWindows component surfaces the per-yard windows on the
loading panel; ReceiveInventoryModal and LoadToTrainPanel wire it in.
- Invalidate loadable-trains/train-loadable-items/warehouse-inventory
queries alongside train-scheduling ones, since they render off the same
data.
Fixes the StationWorkLogJson typo that broke the freight-api build.
- Implemented TransitClearanceActionPanel component for transit agents to handle DO/RO uploads and amendments.
- Added file picker for uploading documents with validation for vessel arrival and collection dates.
- Introduced modals for uploading T1 documents and requesting RO amendments.
- Enhanced transit assignments service with new API endpoints for clearance history, GL exchange documents, and incident reports.
- Updated types to include new document upload sources and statuses.
- Created CSS styles for transit bookings table to improve layout and responsiveness.
- Exported new TransitAgentBookingDetailPage for detailed booking views.
