Mode column in the per-QSO table, readable (FM/SSB/CW) #15
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/entry-mode-column"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The manager's entry drill-in showed no Mode column, so the mode could not be controlled at all.
What the column does
The shared per-QSO table (entrant preview, confirmation, manager drill-in, live sessions view) gains Mode, rendered in the reglement's own vocabulary:
app.rules.flags.cc28b0b.MODE_NOT_ALLOWEDmarker, so the manager sees exactly what was logged and adjudicates it - never a rejection.Verified live
Entry 1 (PD1SCO): FM/SSB shown per row. Entry 4 (PD9MODE): DG and RY rows raw + marked.
Tests: 312 (5 new).
The manager's entry drill-in showed no mode, so the mode could not be controlled there at all. The shared per-QSO table (preview, confirmation, manager drill-in and the live sessions view) gets a Mode column fed by a display helper: - The mode is rendered in the reglement's own vocabulary: FM, SSB, CW. SSB's emission labels USB/LSB are ACCEPTED and read as "SSB" (owner: do not disapprove them), the same normalisation the flag layer and the live logger apply - so a logged USB is an ordinary SSB row, no finding. - EDI's numeric mode codes never reach the table (1/2/6 are translated at parse time); a mode outside the reglement keeps its RAW value ("DG", "RY") with a MODE_NOT_ALLOWED marker on that row, so the manager can adjudicate what was actually logged. - A blank mode renders as an em dash - EDI allows an empty mode column by the standard, so absence is not a finding. Verified on the running stack: entry 1 (PD1SCO) shows FM/SSB per row; entry 4 (PD9MODE) keeps DG and RY with the marker. Tests: 312 (5 new).