mirror of
https://github.com/Tria-plc/edr-platform.git
synced 2026-08-26 18:42:49 +00:00
1f11c3a4ca
customers, contracts, invoices, payments, train schedules, and locomotives / trains / wagons via the fleet page's config. FilterBar pages pass controls.params into the children slot. The four pages still on ad-hoc filtering pass their own hand-built filter object instead, which is why ExportButton takes plain params rather than a UseFilters — it would otherwise have been blocked behind migrating those pages. FleetResource serves seven slugs from config, so it gets an optional exportKey there and renders nothing for the four slugs with no dataset yet. Auditing each page's real filter keys against the dataset declarations turned up three gaps where an on-screen filter would have silently not applied to the export: invoices sends a singular "status" (the dataset only had the multiselect "statuses"), contracts sends paymentCurrency, serviceTypeId and route origin/destination, and train schedules sends freightType. Added all of them — contract routes filter through EXISTS on contract_routes since they are one-to-many, and train-schedule freightType through EXISTS on the bookings aboard, matching the list service. Verified in the browser: the button renders on each page, and the invoices dialog follows that page's own filter object — selecting Paid moves the count from 126 to 100, which matches the database. Filter pass-through checked against the database for invoices, payments, wagons, contracts and train schedules.