A log sent to hamlog.online by hand — an ADIF exported from OpsLog and dropped
on their site — had no way of being marked as sent afterwards. The QSL Manager
then listed every one of those contacts as backlog and offered to upload them a
second time.
Both HAMLOG keys join the bulk-editable extras, so a selection (or the whole
log) can be stamped in one pass. They are DATES rather than Y/N flags because
that is the shape the sent stamp already uses: the QSL Manager's backlog asks
whether the key is present, and a date also says when it went.
The test pins that they are reachable through the extras path and NOT offered as
columns — a mapping claiming both would write to a table that has neither.
They were excluded as "per-QSO", alongside callsign and date. That rule confused
two different things: bulk edit is not for describing QSOs, it is for REPAIRING
a batch of them — an import that mapped every contact to SSB, an ADIF that
carried no MODE at all. Refusing because a hundred rows should not normally
share a value left the operator editing a hundred rows by hand.
Setting the mode CLEARS the submode. A submode belongs to the mode it was
recorded under; left behind it contradicts the new one, and "FT8 with a submode
of USB" is not a thing — worse, the submode is what most ADIF readers believe.
Band is still refused on its own, and that half of the rule stands. It travels
with the frequency through BulkSetFrequency, which writes the pair: a band
contradicting its own frequency is invalid ADIF, and every export would carry
the contradiction out into the world. Callsign and date stay out too — they
identify the contact rather than describe it.
rouggy