mirror of
https://github.com/Tria-plc/edr-platform.git
synced 2026-08-26 18:42:49 +00:00
c8b44d4d04
A station target's plan is per station AND per cargo type; the other two dimensions already carry the category inside dimension_key. update() kept whatever was stored whenever the payload omitted the key, and the admin form builds its payload from visible fields only — so switching "Plan by" away from Station left the old category behind on a row that no longer has any use for one. That row is not merely untidy. It survives the COALESCE(cargo_category,'') unique index alongside the legitimate null-category row for the same key, plannedRowsSql groups by the column, and the two plan rows then join the same operated row through the FULL OUTER JOIN: the category lists twice, each line carrying the full operated tonnage, while the summary tiles are computed separately and stay correct — so the table disagrees with its own totals and nothing says why. create() and update() now resolve the slot through one place, which is the point: the two paths cannot drift again. cargoCategory is derived from the effective dimension rather than carried over, and a station target without one is rejected instead of stored as a plan the report can never match. dimensionKey is checked against the vocabulary the reports actually emit — CARGO_CATEGORIES / CONTAINER_CLASSES, or live yards.code for stations. An unknown key used to store fine, list fine and fall back to showing the raw key, while being a plan no report would ever find. Also drops @Global from the module. Nothing outside it injects either service; the reports read both tables in raw SQL, so the docstring's stated reason for being global was not true.