table_sorting

Technical Spec

Table sorting (shared) — Ver 1, 2026-09-07

Where: templates/base.html, one IIFE at the bottom of the page plus the th.sortable CSS. No per-screen JavaScript.

Opting in: <table class="sorttable">. On DOMContentLoaded every thead th is made sortable and given an ▲▼ arrow, except:

class="nosort" — button/action columns (Actions, Detail)
class="toggle" — the expand chevron column
an empty heading, or a heading containing an <input> (select-all checkbox)

Behaviour

Click sorts ascending, click again descending. Only one column is active.
Sort key is the cell's data-sort attribute if present, otherwise its text. An em dash counts as blank, and blanks sort last in both directions.
A cell is compared numerically only if the whole cell matches ^[-+]?\$?[\d,]+(\.\d+)?%?$. This matters: parseFloat("2026-08-29") is 2026, so loose parsing silently destroys date sorts (found in test, 2026-09-07). Everything else uses localeCompare(..., {numeric: true}), which orders 9d before 10d.
data-pin rows (the Unattached row on the issues summary) stay on top.
data-sub rows (PO Workbench expand-row, PO Release Report det) travel with the row above them, so a drill-down never separates from its parent.
Purely client-side over rendered rows — server-side caps and filters are untouched.

Screens using it: RO Issues summary and detail list, RO Inbox, RO Import History, Pick Review (open + posted lists), PO Workbench, Buy List, Saved Buy Lists, PO Alerts, PO Release Report, PO SKU detail, Count List, Users.

Not converted: ro_inquiry.html and ro_order.html sorted before this change and keep their own inline implementation (their tables deliberately exclude several columns and the RO detail expand row is handled by that screen's own script). If they are ever touched again, move them onto sorttable and delete the duplicate JS.