mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 05:26:47 +00:00
Maurice
f574e75dbe
The export ordered each day by itself, on day_plan_position — one global number per booking, seeded automatically from the place count of whichever day happened to render first. On any other day of a span it therefore pointed at the wrong slot, and where it was still null the export fell back to the order the API returned rows in, which is reservation_time ASC with nulls first. That is why the same trip printed correctly some of the time and swapped two bookings the rest of it, and why the reporter's workaround worked: adding a place and removing it again reseeded the position from the day they were looking at. The plan has never used that column. It picks transports per day, gives each one the time that day shows, inserts them among the places and re-sorts the whole day by the clock — and none of that was reachable from here, because this file had its own copy of the ordering with subtly different rules. So the copy is gone and the export goes through utils/dayMerge, the same functions the plan uses. Two differences fall out of that, both of them the plan's existing behaviour: a booking attached to a place is no longer printed twice, and a multi-leg journey prints one row per leg at each leg's own time rather than one row carrying every leg as a subtitle. The per-segment booking code #1943 added is read back from the booking, since the leg object does not carry it. Closes #1978